- Test - lists.nanog.org

Re: links on the blink (fwd)
by hwb＠upeksa.sdsc.edu 08 Nov '95

08 Nov '95

I think Dave has the right idea here. Given the lousy overall network performance that I (and others) are often seeing for months from varieties of service providers, I think the service providers should be forced to provide rebates. I frequently have 10% packet losses to get from where I am to the Bay area (via New York). And my service provider (CERFnet) is telling me that their service provider (Sprint) is not even answering to their trouble reports. Forwarded message: >From nobody Thu Nov 2 04:40:21 1995 X-Authentication-Warning: upeksa.sdsc.edu: nobody owned process doing -bs Message-Id: <199511021201.AA05016(a)quark.isi.edu> To: Kate Lance <clance(a)sol.newcastle.edu.au> Cc: J.Crowcroft(a)cs.ucl.ac.uk, end2end-interest(a)ISI.EDU Subject: Re: links on the blink In-Reply-To: Your message of "Thu, 02 Nov 95 15:26:44 +1100." <199511020426.PAA22322(a)lily.newcastle.edu.au> Date: Thu, 02 Nov 95 11:55:17 +0000 From: Dave Mills <D.Mills(a)cs.ucl.ac.uk> jon, Kate, Lack of specific performance data is surely disappointing; however, I used to work for COMSAT, so understand the corporate mentality of such dinosaurs. Let me suggest we mount an ongoing experiment in which representative links of deserving carriers are monitored, perhaps with pings launched from cron jobs, and the results submitted for publication in respected national media, like ISOC, ACM CCR, NY Times, etc. One of my (failed) missions at COMSAT was to persuade the lawyers to approve a tariff filing for a packet satellite service. Their stated opposition was based on an assumption that COMSAT would have to rebate charges for those packets not actually delivered to the destination gateway. Our course is clear. File requests for refund with the cognizant public utilities commission. The FCC would of course laugh; however, the reaction of the <state> PUCs would be most interesting, especially if it was pointed out that the rationale for granting the license in the first place was service to the public sector. Dave

11 19

Re: links on the blink (fwd)
by Jeff.Ogden＠um.cc.umich.edu 08 Nov '95

08 Nov '95

I beleive in more accountability and less blame, but in my experience more ink on paper does not necessarly give you that result. Ink on paper often seems to be what lawyers use when the go to court and you go to court after the other less formal methods have failed. Now having some standards for what acceptable performance is and keeping some statistics showing what performace has historically been for a given network and having some good way for one network to work with others to resolve problems -- all of that seems to offer more hope than working on legal contracts. -Jeff Ogden Merit/MichNet

1 0

Re: links on the blink (fwd)
by Sean Donelan 08 Nov '95

08 Nov '95

>worked so hard on achieving. My hope was that you guys would do better >than we did, and provide a ubiquitous high quality network (we did high >quality, but not ubiquitous). Are you going to get to work and fix it, >or continue to screw it up and whine around about the heat in the >kitchen? Your choice. It may just be culture shock going from the role of Internet insider, to Internet outsider. But from the point of view of someone who has always been an outsider, things don't really seem that different than they have in the past. The net goes through cycles of good bandwidth headroom years, and lean bandwidth headroom years. The engineers have always been too busy trying to hold the whole mess together to explain to the Internet populace what was going on. End-to-end network usability has been a persistent problem for the decade+ I've been using the net. The Internet insiders may have been working very hard on management issues. But from the outsider's point of view, the historical net cycle goes something like this. The net's usability slowly declined over the years until reaching a level even network engineers couldn't hand over, then it would suddenly take a leap to a new bandwidth plateau. Yes, network engineers have a long history of finger-pointing and handwaving. But in the past there wasn't anyone who could give a second-opinion. The few end-users who try to measure their perception of the network usability have historically been shouted down. It doesn't seem to matter if there is a high correlation between ping loss rate, and user perception of network performance. All the network engineers know this is a "flawed" testing methodology. This isn't unique to the Internet community. End-users who have the audacity to test their own electrical, telephone, or water service are usually greeted with equal scepticism in by those industries' engineers. Ok, maybe "Internet Management" is an oxymoron. But the lack of centralized management isn't always a bad thing, as long as we can find some invisible hand to guide us. NOC trouble ticket practices, accounting, measurements, and so forth have been on and off the IETF agenda for years. If they were easy problems, I suppsoe they would be solved by now. How about a few positive suggestions which could be implemented in the short-term. The NSFNET Newsletter, Network Status Report list, monthly statistics, and the asnnn(a)merit.edu and techs contact lists were helpful in generating a consensual reality. Perhaps IDG would be interested in publishing a NANOGWorld, free to "qualified" subscribers chock full with exciting cisco advertisements :-). In the meantime, Sprint's outage list, and UUNET's uunet.status newsgroup, and PSI's and UUNET's World Wide Web pages keep folks informed their network status. I wish more network providers had these services. I wish my own network providers provided these services. Statistics seems to be the toughest issue. But also an important one for communicating the state the net with Internet outsiders. AT&T always tells the world how many phone calls were made through its network on Mother's day, or after an earthquake. There are two reasons for this. One is to say how important AT&T is. The second, more important reason, is to help generate a state of mind in their customers why the network may have flaked out on those days. Yes, statistics can lie. But even hard lies are better than hand-waving. And finally, a plea for a common method of notifying a network provider's NOC of a potential problem. If you never hear about the problem, how can you fix it. I understand everyone gives their own customer calls priority. But sometimes even my provider's provider's provider can't figure out how to contact different noc's. noc@somewhere, trouble@whatever, engineer@wherever, action@whoever, etc, etc, etc. My rolodex is crumbling under the weight of keeping track of who works where this week. If folks want to write a Best Common Practice, this is one area that could really use it. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: links on the blink (fwd)
by Steven J. Richardson 07 Nov '95

07 Nov '95

>From list-admin(a)merit.edu Sat Nov 4 15:13:10 1995 >Date: Sat, 4 Nov 1995 12:48:36 -0800 (PST) >From: Michael Dillon <michael(a)memra.com> >X-Sender: michael(a)okjunc.junction.net >To: Hans-Werner Braun <hwb(a)upeksa.sdsc.edu> >cc: Mike <mn(a)tremere.ios.com>, nathan(a)netrail.net, nanog(a)merit.edu, > D.Mills(a)cs.ucl.ac.uk >Subject: Re: links on the blink (fwd) >In-Reply-To: <199511041859.KAA08467(a)upeksa.sdsc.edu> >Message-ID: <Pine.LNX.3.91.951104123440.12997A-100000(a)okjunc.junction.net> >On Sat, 4 Nov 1995, Hans-Werner Braun wrote: > >> I will not go into a point by point rebuttal here, even though I >> generally do not subscribe to your arguments. I am not planning on >> "winning" here, I just want to get the issues on the table and evaluate >> the solution space. Just let me ask you, as a customer who fairly >> frequently experiences 10% packet loss between major Internet locations >> across major service providers (no mom and pop shops in the middle or >> at the end points), how would you suggest I deal with that? > >Uh... Ignore it? >10% packet loss is quite within the normal range of parameters for a >packet switching network such as the Internet. If you want 0% packet loss, >you can lease your own private point-to-point lines. Uh... Michael, when we were running the NSFNET, as Hans-Werner and many readers of this list are well aware, we did _not_ accept 10% packet loss on any link or across the network. These problems stayed with the NSFNET NOC until resolution by the provider, MCI. We only considered -0%- loss to be acceptable. Sorry if others also responded to this, Steve Richardson/Merit >Michael Dillon Voice: +1-604-546-8022 >Memra Software Inc. Fax: +1-604-542-4130 >http://www.memra.com E-mail: michael(a)memra.com

3 2

clarification: Re: links on the blink (fwd)
by Curtis Villamizar 07 Nov '95

07 Nov '95

btw, That's 10^-5 packet loss (0.001%). I just got email asking what the units were. I think the acceptance test uses 1000 byte packets. Curtis ------- Forwarded Message Received: from interlock.ans.net (interlock.ans.net [147.225.5.2]) by brookfield.ans.net (8.6.12/8.6.12) with SMTP id AAA18009 for <curtis(a)brookfield.ans.net>; Tue, 7 Nov 1995 00:09:43 -0500 Received: from merit.edu by interlock.ans.net with SMTP id AA29086 (InterLock SMTP Gateway 3.0 for <regional-techsers(a)ans.net>); Tue, 7 Nov 1995 00:09:41 -0500 Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.6.12/merit-2.0) with ESMTP id XAA11602; Mon, 6 Nov 1995 23:15:13 -0500 Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id XAA17732; Mon, 6 Nov 1995 23:14:47 -0500 Message-Id: <199511070414.XAA17732(a)brookfield.ans.net> To: "Steven J. Richardson" <sjr(a)merit.edu> Cc: hwb(a)upeksa.sdsc.edu, michael(a)memra.com, D.Mills(a)cs.ucl.ac.uk, mn(a)tremere.ios.com, nanog(a)merit.edu, nathan(a)netrail.net Reply-To: curtis(a)ans.net Subject: Re: links on the blink (fwd) In-Reply-To: Your message of "Mon, 06 Nov 1995 15:18:15 EST." <199511062018.PAA08597(a)home.merit.edu> Date: Mon, 06 Nov 1995 23:14:45 -0500 From: Curtis Villamizar <curtis(a)ans.net> In message <199511062018.PAA08597(a)home.merit.edu>, "Steven J. Richardson" write s: > > Uh... Michael, when we were running the NSFNET, as Hans-Werner and > many readers of this list are well aware, we did _not_ accept 10% packet > loss on any link or across the network. These problems stayed with > the NSFNET NOC until resolution by the provider, MCI. We only considered > -0%- loss to be acceptable. Steve, Enough of your wild stories of -0%- loss. :-) The correct figure was 10^-5 for acceptance with 10^-4 being the maximum threshold we would accept on a running circuit before contacting MCI to take the circuit in a maintenance window for diagnostics. That doesn't mean we wouldn't bug MCI to get the circuits back perfectly clean. ;-) We still have the same criteria. I think MCInet is also as vigilant. Curtis ------- End of Forwarded Message

1 0

one typo correction...
by Steve Heimlich 06 Nov '95

06 Nov '95

Change "aggregate" to "advisory" as below. Steve ------- > Date: Mon, 06 Nov 1995 18:43:22 -0500 > From: Steve Heimlich <heimlich(a)kingbee.ans.net> > To: nanog(a)merit.edu > Subject: AS690 policy configuration changes > > > All, > > Starting with Friday morning's config run, AS690 will pick up any > route listed in various routing registries, including both those > routes with advisories and those routes without advisories. > > ANS customers will not be affected by this change. > > Routes without advisories will be examined for origin AS and will > inherit the most popular policy currently used for that AS. For > example, if a route for 147.225/16 (origin AS1660) were listed > without an advisory, we would configure ourselves to listen for > 147.225/16 in the same way that we listen to most other AS1660 > routes (only from AS 1324 in this case). > > If a route is registered in an AS for which we don't have existing > policy, it will not be routed. In the example above, if 147.225/16 > were registered without an aggregate, and it were the only route ^^^^^^^^^ This should be "advisory." [...]

1 0

AS690 policy configuration changes
by Steve Heimlich 06 Nov '95

06 Nov '95

All, Starting with Friday morning's config run, AS690 will pick up any route listed in various routing registries, including both those routes with advisories and those routes without advisories. ANS customers will not be affected by this change. Routes without advisories will be examined for origin AS and will inherit the most popular policy currently used for that AS. For example, if a route for 147.225/16 (origin AS1660) were listed without an advisory, we would configure ourselves to listen for 147.225/16 in the same way that we listen to most other AS1660 routes (only from AS 1324 in this case). If a route is registered in an AS for which we don't have existing policy, it will not be routed. In the example above, if 147.225/16 were registered without an aggregate, and it were the only route registered with origin 1660, then we will not route it. We have a tool which flags such new ASes, and policy toward them will be created regularly. The rate of growth in number of ASes is not high, particularly relative to the rate of growth in number of routes. For now, we will continue to build our policy dynamically from the advisory attributes. Assuming that this hybrid deployment goes well, we intend to freeze our policy and convert to a system which ignores advisories altogether. With this system, the mechanics of shifting policy will be quite easy (essentially involving only ANS). I expect to announce that freeze and shift in the next week or so. At that point, those folks who want to strip AS690 advisories from any database may do so without a problem; as mentioned above, any advisories registered after that time will be ignored. Steve

1 0

Re: links on the blink (fwd)
by Vadim Antonov 06 Nov '95

06 Nov '95

Paul Vixie wrote: >(As long as I'm singing the GIGAswitch's praises, I'd like to add that DEC >is planning a GIGAswitch-to-GIGAswitch interconnect product but it will only >run at a few hundred megabits, not the full b/w of the crossbar; and further, >they now sell an ATM version of the GIGAswitch in case you don't want FDDI >but you need an ATM with working congestion control.) It also supports full-duplex FDDI, which is about as fast as ATM/AAL5 over OC-3 and has no ATM problems (i.e. things like multicasting work as they are supposed to). Now if only YFRV produced devices which could talk full-duplex FDDI and native IP over SONET... --vadim

1 0

More on IPSPA.ORG
by Tim Bass 06 Nov '95

06 Nov '95

Okay, so I am a little nuts. I've sent a domain template to the NIC for IPSPA.ORG.... It just seemed like the right thing to do :-) 1) Next week, I'll register IPSPA as a non-profit corp in some nice state; 2) Maybe we will get lucky and have some members; 3) We will build low cost NAPs for IPSPA.ORG members; 4) We will aggressively solicit corporate and government funding for projects; 5) We will drink beer and eat pizza at our meetings; 6) We will throw together an IPSPA.ORG home page; 7) We can watch all the big IP players laugh as we grow and take a lot of abuse as a new organization; 8) We might even draft an IPSPA post NSF AUP for fun and address topics like child pornography, spam, and other impossible topics; 9) We will hire Washington lawyers to advocate our position on every front in the beltway and use PGP as a rule; 10) Maybe we will form a non-profit common carrier while we are at it and substantially reduce all IPSPA.ORG members transit costs; 11) We will have our meetings only in the best climates depending on the season; 12) We will think of ways as a 'new frontier' network based organization to generate income ( and beg money from members ); 14) We will create a board of directors that are not enjoy well defined conflicts of interests (maybe); 15) We will apply to the FCC for our on set of frequencies to develop lost cost wireless access at T1 speeds and above. Between laughing and while we are waiting on the new domain and I get motivated and fix Majordomo..... IPSPA-request(a)ipspa.silkroad.com soon to be: IPSPA-request(a)IPSPA.ORG Why not? Other ideas and organizations have happened. Stranger things have happened..... and with enough support... who knows? Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include<campfire.h> | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+

8 17

Re: More on IPSPA.ORG
by Eric Kozowski 06 Nov '95

06 Nov '95

>> 3) We will build low cost NAPs for IPSPA.ORG members; > >You laugh ... however, RTD is a few short weeks away from having NAPs up >and running in Tucson and Phoenix. > >It's primarily intended for local providers, so that we can at least >control quality standards in the region ourselves. If larger peers want >to show up, nobodies going to kick them out of bed though...we've got a bed >big enough for everybody. hehe. A NW peering point is currently about 3-4 weeks away. Initially it will be done via fully meshed frame relay, until traffic dictates otherwise. This peering point will be _solely_ for keeping local traffic local and not for providing transit. If anyone is interested, there is a mailing list, nw-internet(a)structured.net (subscription requests to majordomo(a)structured.net) setup for discussing this. Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1

1 0