- Test - lists.nanog.org

Re: Initial Route Server Stats for MAE-East
by Steven J. Richardson 24 Oct '95

24 Oct '95

Tim: 1) I'm Steve, not Richard. 2) Yes, I did find your analogy (which you admitted was "crude") to be offensive. That was my point. I really don't see the point of that sort of comment in a technical discussion. also... >From bass(a)dune.silkroad.com Tue Oct 24 16:09:07 1995 >From: Tim Bass <bass(a)dune.silkroad.com> >Message-Id: <199510242006.QAA06544(a)dune.silkroad.com> >Subject: Re: Initial Route Server Stats for MAE-East >To: sjr(a)merit.edu (Steven J. Richardson) >Date: Tue, 24 Oct 1995 16:06:08 -0400 (EDT) >Cc: young(a)mci.net, curtis(a)ans.net, mnasto(a)franklin.nysernet.org, > mo(a)uunet.uu.net, nanog(a)home.merit.edu, wbn(a)merit.edu >In-Reply-To: <199510241659.MAA17828(a)home.merit.edu> from "Steven J. Richardson" at Oct 24, 95 12:59:40 pm >> >> >' make sure to put all the hair in your pants before >> > zipping your zipper..... notes ... SPAMtastic >> >> Is this really necessary? I don't see any technical point in this >> sort of argument. >> > >No, Richard, it is not 'really necessary'. I hope that you did not >find my crude analogy offensive. >I plead guilty to taking >my opinion to somewhat arrogant extremes in the above statement. >Furthermore, I made the mistake of thinking that this tread was on >com-priv. Ah... >If I had been more cognizant of the fact that this >discussion was on nanog, I would not have posted such a harsh >critique. > >My mistake, too quick on the elm keys, for sure. Thanks > >Regards, > >Tim Steve Richardson/Merit

1 0

Re: Initial Route Server Stats for MAE-East
by Steven J. Richardson 24 Oct '95

24 Oct '95

>From list-admin(a)merit.edu Sun Oct 22 22:24:49 1995 >From: Tim Bass <bass(a)dune.silkroad.com> >Message-Id: <199510230155.VAA03167(a)dune.silkroad.com> >Subject: Re: Initial Route Server Stats for MAE-East >To: young(a)mci.net (Jeff Young) >Date: Sun, 22 Oct 1995 21:55:04 -0400 (EDT) >Cc: mnasto(a)franklin.nysernet.org, mo(a)uunet.uu.net, curtis(a)ans.net, > wbn(a)merit.edu, nanog(a)home.merit.edu >In-Reply-To: <199510230104.VAA15334(a)foghorn.reston.mci.net> from "Jeff Young" at Oct 22, 95 09:04:19 pm >X-Mailer: ELM [version 2.4 PL24 PGP2] >MIME-Version: 1.0 >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit >Content-Length: 1915 >Status: RO > Tim: >' make sure to put all the hair in your pants before > zipping your zipper..... notes ... SPAMtastic Is this really necessary? I don't see any technical point in this sort of argument. >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 */ | >+--------------------------------------------------------------------------+ Steve Richardson speaking for himself, not Merit Network, Inc.

2 1

bcast LQM
by William Allen Simpson 24 Oct '95

24 Oct '95

> From: Curtis Villamizar <curtis(a)ans.net> > LQM on non-PPP links sure would be great. A number of times I've > suggested we consider LQM on bcast, with a set of LQM parameters per > ARP entry. This way one end sends a LQM packet that serves as a time > marker, counts packets, then includes the count in the next LQM time > marker. The receiver needs only count packets between LQM packets and > compare the local count against the count sent by the other end. This > is an enormously oversimplified summary of LQM, but it just to make > the point that LQM is Good Stuff. > Yes, but a bit tough on broadcast, as you would need all nodes sending a history of all the other LQM counts it heard. Quite a big packet or set of packets with many nodes participating. What might be a better idea is to add it to BGP-n. Say between routing peers. That's what I did for IPng, in my (now mangled) Neighbor Discovery. > In the absence of LQM we have the DS3 MIB (poor substitute) Hey, the original PPP LQM was designed and built for DS3 (at Network Systems). NSFnet was very interested at the time. Aren't we already running PPP LQM for all the DS3's? PPP LQM was one of the reasons for PPP/FrameRelay, too. Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1

Re: IPPM: Measuring IP performance
by Guy T Almes 24 Oct '95

24 Oct '95

Kent, Two minor changes, but I'd like to underscore the rest of your note. -- Guy At 09:11 PM 10/23/95 -0800, Kent W. England wrote: > >Then there is treno, Matt's latest tool. From a note by Matt to IPPM list: > >" >... send a note to ippm-request(a)psc.edu. this should now be <ippm-request(a)advanced.org> > >>From the draft charter: >The IPPM WG will develop a set of standard metrics that can be applied to the >the quality, performance and reliability of an IP datagram service. These >metrics will be designed such that they can be performed by the providers >themselves, customers, potential customers or independent testing groups. The work is now organizationally taking place within the Benchmark Methodology WG, and we'll be meeting at the Dallas IETF. -- Guy

1 0

IPPM: Measuring IP performance
by kwe＠6SigmaNets.com 24 Oct '95

24 Oct '95

At 5:44 PM 10/22/95, Brett D. Watson wrote: > > Has anyone come up with *any* way to measure network performance (packet >loss, throughput, delay) other than ping and traceroute? ttcp with a good tcpdump sniffer is very useful. Matt Mathis, sparkplug of the IPPM, invented "wping" which is useful but dangerous to use because of loading. Then there is treno, Matt's latest tool. From a note by Matt to IPPM list: " ... send a note to ippm-request(a)psc.edu. >From the draft charter: The IPPM WG will develop a set of standard metrics that can be applied to the the quality, performance and reliability of an IP datagram service. These metrics will be designed such that they can be performed by the providers themselves, customers, potential customers or independent testing groups. There is now a home page at http://www.psc.edu/~mathis/ippm, including pointers to the minutes, etc. " ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~ Kent W. England <URL:pots://619.632.8400/Hello,Kent?> Six Sigma Networks <URL:fax://1+619.632.8400/SEND> 1655 Landquist Drive, Suite 100 <URL:mailto:kwe@6SigmaNets.com> Encinitas, CA 92024 <URL:pagerto:kwe-pager@pbi.net> Experienced Internet Consulting ~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~

1 0

Initial Route Server Stats for MAE-East
by William B. Norton 24 Oct '95

24 Oct '95

Hi all - Since the deployment of the RSes at the interconnection points the RA team has been collecting network statistics including packet loss and latency across the media to our peers, BGP message counts, RS memory utilization, various interface counts on the RS, and so forth. We have installed a sample web page containing data collected at the MAE-East facility. Over the next month we will finish up the automated portion of the data collection and report generation for the rest of the interconnection points. Our MAE-East data is located at http://www.ra.net/~ra/statistics. Feedback and suggestions welcome. We will try and incorporate your ideas into the layout for next month. Thanks to Dun Liu and Susan Horvath for putting all of this together. Bill ------------------------------------------------------------------------- William B. Norton Merit Network Inc. e-mail: wbn(a)merit.edu phone: (313) 936-2656 WWW: http://home.merit.edu/~wbn

10 16

Re: MAE-East
by Vadim Antonov 24 Oct '95

24 Oct '95

"William Allen Simpson" <bsimpson(a)morningstar.com> wrote: smd> I should also note that Sprint and MCI are in the final smd> phases of negotiating direct point-to-point peerings... >You mean, we might end up with a Network instead of a Treework!?!? Net-work: n., Russian-English. 1) Any computer network, compare with meaning 2. 2) Literally: "No-work", or does not work; meaning the sustained state of a computer network (see 1). --vadim

1 0

Re: MAE-East
by William Allen Simpson 24 Oct '95

24 Oct '95

Sarcasm warning.... > From: Sean Doran <smd(a)icp.net> > A couple quick points: the place to go to for this kind > of thing should be your direct service provider, who hopefully > has some means of communicating with upstream and peer providers > when things are going wrong somehow, or at least might be > able to give you some additional information. > It should not surprise you that I am no stranger to the folks at my "direct service provider", on either the local or national sides.... > NANOG and other lists aren't appropriate places to discuss > specific problems. OTOH, general problems, such as how big > the Internet is and how saturated well-known-things seem to > be and what might be done about it, could be OK here. > IMnsHO, the _only_ way to discuss engineering is with specific problems! NANOG is damn well the appropriate place to discuss _this_ specific problem! The problem is trying to cram the entire world's traffic through a few NAPs, instead of many MIXs. The problem is the outright failure of the design of the first NAPs, particularly the MAE-East "ethernet" and the "ATM" NAPs. The problem is scaling, and the _cheapness_ of the commercial providers in failing to provide widespread interconnections with each other. > I should also note that Sprint and MCI are in the final > phases of negotiating direct point-to-point peerings which > will pop up in several areas, and improve connectivity > between SprintLink and InternetMCI. You wouldn't be far off > in expecting this to become something of a trend, > particularly among a small number of the large heavy-traffic > providers, for whom the NAP/MAE/FIX concepts and models > don't seem to be scaling well in practice. > You mean, we might end up with a Network instead of a Treework!?!? Halleluia! Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

mae-east dampening/flapping view
by Ed Kern 23 Oct '95

23 Oct '95

Dont know if this would be of intrest to a soul (outside DIGEX), but if you ever have a need.. http://nitrous.digex.net/mae-lg.html Will let you view/use trace dampened-paths flap-statistics bgp summary version ping Comments to me directly please. Ed PS all hits will be logged so I can lock out the abuses, but all logs will remain private.

1 0

Re: MAE-East
by Brett D. Watson 23 Oct '95

23 Oct '95

That was precisely the point of my last note. I *want* to get involved in finding a reliable way to measure network performance and I *want* to be proactive at it. I absolutely hate telling customers that "pinging a cisco is not a good indicator..." but like you say "there ain't no other way". Just as ping and traceroute are not good indicators of performance, saying that they aren't good indicators is *not* acceptable to customers paying money for your service. So just for the record, I'm not working for a provider and whining that it's not our fault. I want to find a good way to measure peformance on my network and I'd love to be able to publish some results. Guy Almes contacted me about getting involved and that's just what I want to do. -brett > > A couple quick points: the place to go to for this kind > >of thing should be your direct service provider, who hopefully > >has some means of communicating with upstream and peer providers > >when things are going wrong somehow, or at least might be > >able to give you some additional information. > > Ahem, my success rate at that has been less than stellar. If you guys > (you service providers, not you Sean) are so worried about being asked > questions in public (and short of com-priv, I see no more logical place > for this than NANOG if "local" questions don't work], why don't you > work on schemes to pro-actively publish performance data? Otherwise > you *will* get called to the table based on ping and traceroute data, > there just ain't no other way. Either *you* do it, or others will do it > for you, with the tools they find most appropriate, and all your > whining will eventually be discounted. Be pro-active, or give them > better tools. You *asked* to be in the kitchen, *you* better deliver a > working network, including at the Internet-systemic level and not only > in your own service provider centric environment. I suppose that if > you guys can't figure it out yourself, there is always the opportunity > to get it fixed by someone else. Like, ahem, regulation.

1 0