- Test - lists.nanog.org

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

21 Oct '96

Jeff, I think you may miss the point. In the commercial Internet world, I have to pay for my network. If I'm a big guy, my main value is hauling traffic long distances. How am I to make a profit (or even maintain my network) if 1) I can't exchange traffic with the other long haul providers without significant loss, and 2) I give free access to all of my most opportune customers? I doubt that the people who design, engineer, and install these networks feel at all that way about open naps. They have been driven to a business decision. In many peoples eyes it may not have been the best decision, but it happens to be the easiest and quickest method to quench the bleeding. We are at a point where the traffic growth is causing a lot of people to re-evaluate their network design philosophy. We haven't even begun to see the final shape of thinks (All IMHO) Chris ---------- From: Jon Zeeff[SMTP:jon@branch.net] Sent: Monday, October 21, 1996 2:15 PM To: Chris A. Icide Cc: dalvenjah(a)dal.net; emv(a)coast.net; nanog(a)merit.edu Subject: Re: Ungodly packet loss rates In other words, the big players don't like the "open" naps and are deliberately not installing sufficient bandwidth to them? -- (313) 741-4442 http://branch.com/ Jon Zeeff Branch Internet Services Inc. jon(a)branch.com *** WWW Hosting Services, WWW Site Development and the Branch Malls ***

1 0

Re: Ungodly packet loss rates
by John Hawkinson 21 Oct '96

21 Oct '96

This whole thread really disturbs me. I think the original message that started it was a bit out of line, but only because it was cc-ed to NANOG without giving providers a chance to respond to the criticism. Nevertheless, the posts that followed it were far worse. Ed Vielmetti have suggested interconnects are "to blame" and that if you transit any of them you're likely to see loss, or that if you even take multiple providers to get your destination, you might as well throw in the towel. Dalvenjah FoxFire complains about a similar amount of packet loss across MAE-WEST. Unfortunately there aren't enough details to see if the problem is related. But the implication is that MAE-WEST is at fault. This is pretty unlikely, go look at the graphs on http://www.mfsdatanet.com/MAE/west.stats.html, yourself. It is likely that at any given point some provider may have congestion on one of their links to an interconnect -- surely this does not mean the interconnect was to blame. Bill Bradford suggests you're lucky to get anything approximating a lossless connection. Derek Elder injects irrelevencies about holes in operating systems that make us wish NANOG was a moderated list (too bad the only qualified people don't have time to moderate). To my mind, the right answer is to check with the folks involved! Any other answer falls short. If there is loss somewhere, most providers want to be told about it. In some cases, it's possible to shift traffic around to deal with such problems. In other cases, there may be planned upgrades in the works to deal with the problem. In other cases, they may not even be aware of the problem. To comdemn network providers without even asking them to justify and investigate the loss represented by traceroute on their networks is hardly fair. Oh yes, the second time around, Ed suggests that network operators may have "no hesitation dropping traceroute or ping packets to low priority". No major network provider *drops* traceroutes or ping packets. Many vendors' code (cisco in particular) deprioritizes handling these packets such that round-trip-times are not meaningful; said vendors also rate-limit responses -- this is normally intrusive but might become so in the face of poor testing methodologies. --jhawk John Hawkinson

1 0

Re: Ungodly packet loss rates
by jbash＠velvet.com 21 Oct '96

21 Oct '96

> The wonderful, and possibly the only redeeming quality of the new commercial > Internet is that it is a free market system. You have your choice of which > ISP/NSP to connect to as a dial-up user. Cisco also has a choice as to > which provider to connect to. If either chooses poorly, you can always seek > out those providers which do not oversell their lines, provide UPS > and power generators in case of failure, which peer openly with all networks, > and offer guaranteed reliability. Good providers are available for a price. > However, if you are concerned with price, as a lot of users of certain ISPs > are, then I have no pity.. you simply pay what you get for. Well, I'd agree with you... if the providers I use had told me that I was going to get degraded service. They did not. They told me I was going to get ordinary, decent, usable commercial-quality service. It's true that they offered me a low price, but they offered me a low price for a product that they're not delivering to my satisfaction. Not only that, but the low price I get was explicitly justified by a lack of technical support, *not* by a lack of decent packet delivery. I don't think they were or are deliberately misleading me, or otherwise being dishonest. It seems as though they're following standard industry practice. At this point, the sort of thing I'm seeing seems dangerously close to becoming the accepted standard of service on the Net. Unfortunately, it's not adequate, and it's not what a reasonable person would expect when ordering a service. I make no apology for looking for the best price for Internet service, nor for complaining about it when I don't get that service. In fact, my immediate provider, TLGnet, doesn't seem to have any major internal capacity problems, and they do all the downtime avoidance things you suggest. I've never had a problem with service internal to TLGnet. It's the larger providers that seem to be the problem. TLGnet is at fault only insofar as they have a choice of which backbones to use... and such choice is hardly unlimited. If you want me to contract directly with somebody who has direct connections at all the various interconnect points, I suppose that's a possibility. It doesn't seem to have helped Cisco, though... BBN is pretty big, and there still seems to be lots of loss inside the BBN network. Same for Alternet. I haven't measured it, but I've heard that there are huge loss rates at MCI and Sprint (even if they'd deal with me, which I doubt they would). I'm sure there are others, but who's better? Who'm I supposed to call? How would I even *know* whether somebody had oversold capacity? Assuming that you're right, and that there are better providers, I don't have the dozens of hours it would take me to pore over people's network maps, and to read their technical information in hundreds of different formats. I also have no control over the provider choices of the people I communicate with... and large loss rates seem to be the norm, not the exception. Furthermore, I'm a bit of a rarity in that I actually understand (some of) the technical issues. Most users are no more capable of evaluating an ISP's network design than I am capable of flying to the moon. If they see poor service, they just assume that the Net is intrinsically flakey. I expect the providers I use to give me an appropriate level of service. Unless they've explicitly told me to expect low-quality service, I expect decent quality. From any provider. Regardless of price. That's the issue I'm raising for the providers I'm complaining about, and for other providers (apparently the majority) who are in the same boat. I don't really want to single out TLG, UUNET, or BBN, because as far as I can tell this kind of service is the norm. How much real-world traffic is there that *doesn't* cross at least one network with a high loss rate? For NANOG and the industry as a whole, the issue is the fact that the Internet is still, in some sense, "one thing". If one provider gives poor service, everybody's customers see the results. It does me as a customer little good to buy from a good provider if the people I communicate with are using poor providers. It's therefore in the industry's interest to educate customers, and to have easily applied have quality-of-service standards. I wouldn't make such standards mandatory, but I'd certainly think that they'd be useful to a lot of people, both in choosing services and in explaining to users what they could expect. > Let me stress again.. I seriously doubt this is the appropriate platform for > discussion of which providers are bad.. and therefore.. I'll stop right > here. So, what is the right forum? Is there a seal of approval somewhere? Should there be one? How about a standardized set of service grades? If I knew that I (or the other end of my connection) had ordered grade C service, I wouldn't complain if I didn't get grade A throughput. Right now, there's only one grade: "usable"... and I'm getting something that barely qualifies. -- J. Bashinski

2 1

Re: Ungodly packet loss rates
by jbash＠velvet.com 21 Oct '96

21 Oct '96

[Quotes reordered] > If you want good internet service to a particular point on the network, > you must shop for it specifically and be prepared to continue to shop > for it whenever the underlying network topology changes. My point is that I should be able to expect better than a 40-percent loss rate to *any* point on the Net, at *any* time, from *any* provider. In fact, I think I should be able to expect less than 5 percent, and probably less than 1 percent. Back when I actually touched routers, I used to recommend that people upgrade their internal networks when loss rates hit 1 percent. A situation where I have to "shop around" for connectivity depending on what site I want to talk to that day is just plain unacceptable. > You're transiting two NAPs (MAE-WEST and the DEC exchange (?)) which > both provide service that's essential on one hand (wide access to > the greater Internet) and lousy on the other hand (focussed access > to a particular site). It doesn't look to me as though the loss is being introduced at the NAPS. If you look at the trace, you'll see that significant loss starts to appear within Alternet, well after MAE-west. It looks as though more loss appears inside BBN's network, although it's difficult to tell because of the already large Alternet loss. > my suggestion would be to ask cisco what isp they recommend > for dialup access from your location, and dial in through them. > you should be able to lop off 60% of your hops and probably 99% > of your problems if you pick right. Thanks for the suggestion, but I work for Cisco, so ordinarily I have a Frame Relay connectivity into Cisco's network. This week the computer I usually use for work is in for service. The Cisco LAN at my house is air-gapped from the personal LAN, and it would be a real pain to reconfigure everything, so for the moment I'm coming in to Cisco over the Net, using my personal service. It's purely temporary. If I did interactive work under these conditions on a regular basis, I'd have gone insane long ago. -- John B.

3 2

Re: Creating exchanges
by Thomas P. Koltai 21 Oct '96

21 Oct '96

On Fri, 11 Oct 1996 15:11:29 -0700 (PDT) bmanning(a)ISI.EDU wrote: >> <SNIP> > >Oh... btw, the "wnog" would really be the IEPG. iepg(a)iepg.org >Or, since this has a distinctly PacRim flavor, APOPS. > Nope, can't be IEPG. gih@telstra has already snaffued that one. In April 1994!!!! Geoff, I thought I was a visionary... chuckle. Tom ------------------------- Thomas P. Koltai Phone: +61-2-261-4884 Mobile: +61-414-574-242 185 Liverpool Street, Sydney NSW 2000 -------------------------

1 0

Re: Ungodly packet loss rates
by Edward Vielmetti 21 Oct '96

21 Oct '96

my suggestion would be to ask cisco what isp they recommend for dialup access from your location, and dial in through them. you should be able to lop off 60% of your hops and probably 99% of your problems if you pick right. You're transiting two NAPs (MAE-WEST and the DEC exchange (?)) which both provide service that's essential on one hand (wide access to the greater Internet) and lousy on the other hand (focussed access to a particular site). If you want good internet service to a particular point on the network, you must shop for it specifically and be prepared to continue to shop for it whenever the underlying network topology changes. Ed Edward Vielmetti emv(a)coast.net

2 1

NANOG Meeting Info
by Pam Ciesla 21 Oct '96

21 Oct '96

Shuttles from hotels to meeting: Holiday Inn Thursday 10/24 Depart 8:00AM Pickup at MI Union 5:15PM Friday 10/25 Depart 8:00AM Pickup at MI Union 1:15PM Sheraton Thursday 10/24 Depart 8:00AM Pickup at MI Union 5:30PM Friday 10/25 Depart 8:00AM Pickup at MI Union 1:10PM NOTE: SIGN UP SHEET AVAILABLE AT HOTEL WHEN YOU CHECK IN Pam

1 0

Ungodly packet loss rates
by jbash＠velvet.com 21 Oct '96

21 Oct '96

[Resent... I stupidly used the wrong address for the NANOG list] This is being sent to the "help-line" addresses of several Internet providers because they're not providing what I consider appropriate service. It's being sent to the NANOG mailing list because it represents what I believe to be an industry-wide problem. I'm just a lowly end user, and perhaps I shouldn't intrude into the councils of the Wise and the Great, but this is just a bit ridiculous. Attached is a traceroute from my home machine to the system I'm trying to work on over a TELNET session. It looks like there's about a 40-percent overall round-trip loss rate, most or all of it apparently introduced in the Alternet and BBN Planet backbones. This is not a transient condition; it's been going on for at least several days, and similar things happen all the time. I think we can all agree that a 40-percent loss rate isn't an acceptable level of service in an IP network. It's certainly making it annoying and frustrating for me to try to work. It's also driving up the load on the network by provoking retransmissions. A corporate internal network running at that loss rate would probably be considered to be in collapse. I pay TLGnet (now Best) an agreed-upon amount of money every month, nominally in exchange for a reasonable level of Internet service. I think that part of TLGnet's obligation under that arrangement is to contract for reliable backbone service. Likewise, the other end of the path (Cisco systems, for whom I am emphatically not, *not, *NOT* speaking here) pays BBN what I suspect to be a very large amount of money indeed for DS3 service, presumably in the expectation that most of the packets that go into the DS3 will come out of the network somewhere. Alternet presumably has agreements with both TLGnet and BBN. That puts everybody on the hook. I fully understand that it's difficult to provide reliable service in an exponentially-growing network. I'm aware that everybody's already using the fastest lines they can get, and connecting the fastest routers to them. I know that links are being added. I appreciate that both lines and equipment are very expensive, and that adding lines serves to complicate an already amazingly complex router configuration situation. I understand that cash-flow issues (as well as convincing-the-bean-counters issues) are involved. I sympathize... ... but the fact remains that I'm not getting the level of service I think I'm entitled to, nor are other end users. Not only that, but if the level of service gets any lower, the Net will become so painful to use that I'll start wondering why I bother. While reducing my Net use might be good for my mental health, I don't think anybody wants to see users abandoning the Net because of poor service. So, what's to be done about it? Assuming that all technical means are being pursued, and from what I've seen on various mailing lists I believe they probably are, the only thing left is a management fix. May I make the probably-sacreligous suggestion that the industry as a whole, and the providers I've mentioned in particular, show greater concern for the quality of service provided, and specifically-- 1. Stop taking on new customers (or other traffic sources) until existing customers can be provided with an appropriate level of service. 2. Develop meaningful quality-of-service standards that can be used to guarantee reasonable performance in terms of end-to-end drop rates, delays, and downtime. 3. Reexamine both pricing levels and the Internet pricing model, to make sure that there's enough money available to fund a usable level of service. Yes, this means giving up some business. That's one of the costs of honoring your agreements... and of not alienating an entire generation of customers. Thank you for your attention. Although I usually scan at least the subject lines of messages sent to the NANOG list, I'm temporarily without access to the news server on which I ordinarily read the list. For the next few days, I won't be able to answer replies not sent to me directly. -- J. Bashinski blue% traceroute -a -q 25 -Q champagne.cisco.com traceroute to checkpoint-sj.cisco.com (171.69.10.37), 30 hops max, 40 byte packets 1 tongue.velvet.com (206.14.77.65) (2.8 ms/3.6 ms(+-0.9 ms)/15.8 ms) 25/25 (100.00%) 2 tlg-cust-link.tlg.net (140.174.151.93) (39.0 ms/47.5 ms(+-10.3 ms)/134.8 ms) 25/25 (100.00%) 3 mae-west.tlg.net (198.32.136.22) (40.7 ms/45.6 ms(+-9.2 ms)/57.0 ms) 25/25 (100.00%) 4 905.Hssi3-0.GW1.SCL1.ALTER.NET (137.39.133.89) (43.9 ms/49.1 ms(+-9.9 ms)/60.8 ms) 25/25 (100.00%) 5 Fddi0-0.CR1.SCL1.Alter.Net (137.39.19.5) (43.5 ms/48.8 ms(+-9.8 ms)/57.0 ms) 25/25 (100.00%) 6 Hssi3-0.San-Jose3.CA.Alter.Net (137.39.100.1) * * (45.3 ms/52.5 ms(+-11.1 ms)/77.6 ms) 23/25 (92.00%) 7 Fddi0-0.San-Jose6.CA.Alter.Net (137.39.27.12) * (44.4 ms/49.6 ms(+-10.2 ms)/60.8 ms) 24/25 (96.00%) 8 Hssi1-0.Palo-Alto2.CA.ALTER.NET (137.39.101.162) (46.7 ms/52.6 ms(+-10.5 ms)/61.6 ms) 25/25 (100.00%) 9 Fddi1-0.Palo-Alto3.CA.Alter.Net (137.39.47.7) * * * * * (57.9 ms/82.0 ms(+-21.6 ms)/248.5 ms) 20/25 (80.00%) 10 decwrl.bbnplanet.net (198.32.176.5) * * * * * * (50.4 ms/60.8 ms(+-14.0 ms)/68.9 ms) 19/25 (76.00%) 11 paloalto-br1.bbnplanet.net (4.0.1.57) * * * * * * (52.7 ms/63.6 ms(+-14.7 ms)/82.3 ms) 19/25 (76.00%) 12 paloalto-cisco.bbnplanet.net (131.119.0.196) * * * * * * * (57.0 ms/66.2 ms(+-15.7 ms)/80.7 ms) 18/25 (72.00%) 13 * 131.119.26.10 (131.119.26.10) * * * * * (54.8 ms/65.6 ms(+-15.1 ms)/75.6 ms) 19/25 (76.00%) 14 sj-wall-2.cisco.com (192.31.7.34) * * * * * (48.2 ms/77.2 ms(+-18.4 ms)/151.9 ms) 20/25 (80.00%) 15 * * * * * sj-eng-corp2.cisco.com (198.92.1.130) * * * * * (58.5 ms/70.3 ms(+-18.2 ms)/81.2 ms) 15/25 (60.00%) 16 * eng-atm-gw2.cisco.com (171.69.4.129) * * * * * * * * * (61.9 ms/67.1 ms(+-17.4 ms)/78.7 ms) 15/25 (60.00%) 17 sj-eng-corp1.cisco.com (171.69.5.10) * * * * * * * (52.2 ms/64.9 ms(+-15.4 ms)/81.8 ms) 18/25 (72.00%) 18 checkpoint-sj.cisco.com (171.69.10.37) * * * * * * * * * * * * * * * * (58.1 ms/78.6 ms(+-30.0 ms)/202.2 ms) 9/25 (36.00%)

2 1

Re: GigaRouter (Was Re: Cisco as Big Brother))
by Rob Liebschutz 21 Oct '96

21 Oct '96

I've spent days on the phone with [substitute your favorite router vendor here] customer support and engineers tracking down bugs in their routing software and trying to get bug fixes and workarounds from them, and I've spent comparable days running gdb on gated and staring at gated code and my personal opinion is that working with the gated code was a far more valuable experience for me. Gated is very stable for me now, and if I don't like the way something works, I change it or add a new feature if I want. My experience in consulting has taught me that off the shelf products from vendors with professional customer support (i.e. black boxes approved by Fortune 500 companies) are better for some clients, but I have clients that appreciate software like gated and are willing to pay for my time to work with it. You can always join the gated consortium. The gated web pages at Merit indicate that there is some level of support available for those willing to pay for it. Can anyone with experience comment on this? Is source code and a development environment available (and afordable) for the gated implementation in the Netstar product? If it is and the product is reasonable in other ways, I'd be on their doorstep in a minute. Are source licences available from any of the other major router vendors? > alex(a)relcom.eu.net writes: > > > > > > > > >Subject: Re: GigaRouter (Was Re: Cisco as Big Brother)) > > > >From: dvv(a)sprint.net (Dima Volodin) > > > > > > >You said - "gated"? Oh my gawd... > > > > > > I agree. Oh my gawd, someone is using one of the most efficient and > > > reliable pieces of routing code around. What a really great idea. There > > > are other smart router vendors who use various route and policy storage > > > data structures from gated. Oh my gawd. Some smart router vendors are > > > implementing dynamic non-intrusive policy config on their routers this > > > year. Gated had that 4 1/2 years ago. Oh my gawd. Etc etc... > > > > > > RobS > > Gated would dump core like crazy and lose routes and adjacencies 5 > years ago and it does the same now. Well, on the second thought, I > don't think there's any real reason to bitch about it - all the other > free reference stuff (sendmail, inn, etc, etc. Even 4.4) is plagued > with the same problems. And everybody is kind of accustomed to the > status quo. As of data structures - I remember there was a course on data > structures on my first university year. And you know what? I haven't > seen anything new since then - gated or no gated. > > > Let's compare: > > [...] > > Oh. Don't tell my you do all this on your own and don't use some kind of > conf-generating script. > > > Of cource gated.conf is not (in usial revision) so powerfull as IOS, > > but ideas - ideas in gated was great, and gated works well even now. > > Karl Marx's soul to the soul of Friedrich Engels: "Oh yes. But the idea > was b-e-a-u-t-i-f-u-l..." > > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow > > Dima >

10 12

Re: Cisco as Big Brother (Was Re: Cisco's AIP vs HSSI)
by Michael_Fox＠BayNetworks.COM 21 Oct '96

21 Oct '96

At 02:28 AM 10/18/96 -0500, you wrote: > >In message <199610180717.AAA16438(a)netservice.ca.navigist.com>, "Joe Rhett" writ >es: >> >>> But you can't get one engineer to hack something into the router >>> code for you on just his say-so anymore. But once you could. I dunno >>> maybe you still can, but I think you have to have megabucks behind >>> you to do it. >> >>> Yes, you can, but you have to do it under the table and via direct >>> contacts. And a bottle of cask strength single malt will help. ;-) >> >> >>You know, I find it hard to think of this as a feature - especially >>given the number of times the "quick hack" broke something else. And >>it's always missing the next release of the software. >> >>It takes an Act of God to get Bay to release a fix - but it works when >>they release it, and it works in the next full release too. > >I know of a bunch of very useful things that originated this >way that are in production code on my cisco boxes now. If >sprint had been in a situtation where they need a new feature X >in order to make the network run at all, because no one >had designed they network to grow like it did, I'd hate to have >bought Bay and not be able to get a timely fix. > >I would definately ask my router vendor hard questions about >how quickly a fix will be released assuming I have a "network down" >condition. Bay generally releases fixes every few weeks. For a "network down" situation, if releasing a workspace immediately is the right thing to do, then that's what we do. Who makes the call? The customer, after receiving input from the Bay engineering team. Michael

3 2