- Test - lists.nanog.org

Re: Initial Route Server Stats for MAE-East
by Guy T Almes 23 Oct '95

23 Oct '95

Randy, I agree. In fact, at the interim BMWG/IPPM meeting, Vern made a presentation on his work, and it was well received. -- Guy At 07:28 AM 10/23/95 PDT, Randy Bush wrote: >hate to sound egghead, but this stuff has been the subject of non-trivial >academic (yet practical) research, and there is a fair literature base. >hard to drag out refs from here, but one interesting ongoing project is >NPD by Vern Paxson, <vern(a)ee.lbl.gov>, which might serve as a starting >point for a lit search. some evenings it is nice to take a cs break from >all the grotty hacking. >

1 0

Re: Initial Route Server Stats for MAE-East
by randy＠psg.com 23 Oct '95

23 Oct '95

hate to sound egghead, but this stuff has been the subject of non-trivial academic (yet practical) research, and there is a fair literature base. hard to drag out refs from here, but one interesting ongoing project is NPD by Vern Paxson, <vern(a)ee.lbl.gov>, which might serve as a starting point for a lit search. some evenings it is nice to take a cs break from all the grotty hacking.

1 0

Re: Initial Route Server Stats for MAE-East
by Gerald Andrew Winters 23 Oct '95

23 Oct '95

Hello, I can't resist jumping into this disscussion. I think its clear that there is much work to be done on router/IP performance. The question then is what can be done in the meantime, until said work is completed? Here is a script I wrote that will work on cisco routers. The script takes advantage of cisco's enterprise specific MIB. There are 3 SNMP variables yielding CPU busy percentage. The first is CPU busy percentage in the last 5 seconds of scheduler time. The other two are 1 and 5 minute exponentially-decayed moving averages. The CPU busy metrics can yield interesting results, for example %'s above 40% indicate a busy router. I was able to generate some interesting graphs awhile back for our cisco routers. For more information, use the oid's in the script as pointers into the cisco mib. And here is the script for anyone who is interested. --Gerald Winters <gerald(a)merit.edu> #!/usr/local/bin/perl @mib_objs = ("1.3.6.1.4.1.9.2.1.56.0", "1.3.6.1.4.1.9.2.1.57.0", "1.3.6.1.4.1.9.2.1.58.0"); for ($i = $num_values = 0; $i < 3; $i++) { foreach (`/afs/umich.edu/user/g/e/gerald/CISCO/snmpget -h 141.211.128.1 @mib_objs[$i]`) { if (/value:/) { $num_values++; @values[$i] = /\w+\W+\w+\W+(\w+)/; } } } if ($num_values == 3) { print "@values[0] @values[1] @values[2] ".`date`; } else { print "0 0 0 ".`date`; }

1 0

Re: Initial Route Server Stats for MAE-East
by Guy T Almes 23 Oct '95

23 Oct '95

I'd like to second Mike's note, particularly the call for participation. Learning how to characterize IP clouds with carefully defined metrics of delay, flow capacity, and packet loss will be real work. Note, for example, the discussion this weekend of how simple pings to a loaded router don't yield a good measure of packet-forwarding loss. The same could be said for trying to measure round-trip delay to a loaded router. If you'd like to join the IPPM email list, send mail to <ippm-request(a)advanced.org>. Notes expressing an interest in working on specific kinds of issues would be particularly appreciated. We'll also be meeting at the upcoming Dallas IETF. -- Guy At 10:06 PM 10/22/95 -0400, Mike O'Dell wrote: > >the IPPM effort within the Benchmark Methodology Working Group is >working on "IP Performance Metrics" which apply to large IP networks >viewed as the "device-under-test" and not "provider metrics" per se. >(I say this as the both the Co-Area Director and the AD responsible for >the working group.) > >understanding the performance of complex networks IS a very much >unsolved problems. people are thrashing around taking whatever >measurements they can think of with hopes of generating SOME kind of >understanding. I don't blame them at all - there isn't much else to do >right this instant. > >all this means, though, is that folks concerned with the problem need >to participate in the BMWG efforts. there is a lot of work to do here >and with some luck, we may do some science to the point of developing >some understanding about how to measure and characterize these beasts >we've built. > >A lot has been done in characterizing performance of network elements, >so now we need to draw a bigger circle around what we're testing >but still apply significant rigor and good experimental methodology >so the data will be meaningful. > > yours for more consistent confusion, > > -mo >

1 0

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

23 Oct '95

> From: feldman(a)MFSDatanet.COM (Steve Feldman) > Please send me traceroutes and ping output showing the problems. > Samples when things are working would also be good as a baseline. > > I'd like to see if we can correlate the problems to congestion on > the shared FDDI, or if something's really broken. > You know, it never ceases to amaze me that no matter how much anecdotal evidence is given from however many responsible sources, the answer is "oh, that can't be right, give more data". Even now that we have scads of data, it is declared not to be the right kind. I've posted (to various lists) my traceroute and ping statistics, and each time the conditions were challenged. No, I don't monitor the mae-east link directly, and cannot tell what _kind_ of data is present. But, I POP3 my 150K of email 3-4 times a day over the appended route. My software reports 1-5% retransmission loss during nights, 5-10% weekends, and 20-40% during weekday afternoons. It can take half an hour to move 100KB. MCI and PSI blame each other. But, there's no excuse why they don't peer a little closer to here, since I can point to the few city blocks they are apart! If you want a really good a measure, instead of ping try running NTP over the links in question. It gives a very accurate measurement! And I've observed 40% loss peaks there too! Ping reports the loss to appear between 204.70.1.106 and 192.41.177.245 (the names of the hops in between has changed several times in the past few months without any apparent change in service). Here's a baseline, late Sunday night: Recording Mon Oct 23 03:42:19 1995 Resolving .... 137.175.2.11:33434 1: 35.1.48.52 pm001-03.dialip.mich.net. (3 ms) (3 ms) (3 ms) 2: 35.1.48.48 pm001-aa.mich.net. (184 ms) (244 ms) (181 ms) 3: 35.1.48.2 e-neithernet.c-ccb.umnet.umich.edu. (179 ms) (240 ms) (180 ms) 4: 198.108.3.1 fdd3-0.michnet1.mich.net. (183 ms) (233 ms) (181 ms) 5: 192.203.195.5 cpe2-fddi-1.Chicago.mci.net. (178 ms) (233 ms) (175 ms) 6: 204.70.25.9 border2-hssi2-0.Chicago.mci.net. (186 ms) (239 ms) (181 ms) 7: 204.70.3.81 core-fddi-1.Chicago.mci.net. (186 ms) (234 ms) (194 ms) 8: 204.70.1.94 core1-hssi-2.NorthRoyalton.mci.net. (240 ms) (194 ms) (242 ms) 9: 204.70.1.102 core1-hssi-3.WestOrange.mci.net. (267 ms) (359 ms) (262 ms) 10: 204.70.1.66 core2-aip-4.WestOrange.mci.net. (254 ms) (266 ms) (200 ms) 11: 204.70.1.106 core2-hssi-2.Washington.mci.net. (244 ms) (269 ms) (266 ms) 12: 204.70.74.52 borderx1-fddi-1.Washington.mci.net. (212 ms) (227 ms) (209 ms) 13: 204.70.74.102 mae-east-plusplus.Washington.mci.net. (275 ms) (268 ms) (272 ms) 14: 192.41.177.245 mae-east.psi.net. (268 ms) (230 ms) (205 ms) 15: 38.1.2.11 (233 ms) (267 ms) (273 ms) 16: 38.2.112.6 (277 ms) (274 ms) (308 ms) 17: 137.175.2.11 volitans.MorningStar.Com. (334 ms) (765 ms) (281 ms) traceroute done: normal (Unreachable Port) 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

Traffic Analysis ( was Re: Initial Route Server Stats)
by Tim Bass 23 Oct '95

23 Oct '95

Last one, then i'm dropping of this thread :+ mo hits the nail on the head when he states that detailed performance numbers in complex multihomed interconnected networks are currently unobtainable. In any complex problem with numerous uncertain parameters, variables, and relative metrics all moving on the wire at varying speeds, densities, and with a given broken path 'here or there' at any given moment...... Most practical, day to day network users judge traffic on the net the same way we judge the traffic jams on the highways.... You look out over the overpass and determine the density of the traffic, guess about the status of traffic lights and construction zones, wonder if there was an accident and decide if getting on the ramp is a good idea because, once you do, there is no turning back ( for all practical purposes ). So, you want to know how the traffic is to Washington DC from the suburbs.... one way is to get into your car and drive the round trip to the city and back and then estimate the traffic. Of course, a little Miata moves faster than an semi or Station Wagon with 3 kids and a dog; and that police or fire vehicle gets a higher priority... BUT in general, we know something very simple.... "if it moves slow, it must be slow for some reason" and we generally do not like it. So, here we are, crusin' the network and we want to understand why we can't get to our favorite IP address or IP address of the moment. We PING the thing, knowing full well that it is not Einstein's SuperSpecial Theory of Network Metrics, but at least we can look the the numbers and say.... geezzz... it took a looooong time, must be a lot of traffic. Slow is slow even in zen-metrics. Hey, let's do a TRACEROUTE and guess where the congestion is... While the PHD candidates in EE and CS programs in univs' enjoy digging into into complex network theory, the average day-to-day running the network, answering the phone, or just trying to get out to some site kinda cyberjocky enjoys their only dependable tools, PING and TRACEROUTE. World peace, a perfect universe, harmonic diverity are all interesting topics. So are complex network metrics and and space-time theory.... time travel anyone ? :-) Maybe we need a new Internet Traffic Report Morning Show. Mae-east is hosed today, but will have an new OC12 next week. NET99 is moving over to MCI but having trouble peering with Sprint until further notice. Packets to the convention in the Balkans are being filtered by CIDRites at ICP.... Stay tuned and have a nice day. Now, up to the minute IP security tips sponsored by cisco, your partners in datametrics and virtual resolution protocol. But first, MCI and the ReachOut and Spam Your Friends and Family special offer, after these messages. ................ -- +--------------------------------------------------------------------------+ | 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 */ | +--------------------------------------------------------------------------+

1 0

Re: MAE-East
by Sean Doran 22 Oct '95

22 Oct '95

Wow, major edito. That should be: Thee Temple ov Psychick Youth I blame T.V. for the mistake. Sean.

1 0

Re: MAE-East
by Sean Doran 22 Oct '95

22 Oct '95

Wow, major edito. That should be: Thee Temple of Psychick Youth I blame T.V. for the mistake. Sean.

1 0

Re: MAE-East
by Sean Doran 22 Oct '95

22 Oct '95

I echo the comments of Steve Feldman. Unfortunately none of the folks on the nanog list are psychic, and in the absence of anything remotely approaching quantitative data, I for one am at a loss to explain the variance in my experiences with MAE-EAST+ (I pass lots of traffic through it at all hours) and the impressions of Scott and Ran. Please supply some real information so that we can see if there is a real fix for things, or even a real problem. Sean. (of Thee Psychick Youth (how's that for an obscure allusion?))

1 0

Re: MAE-East
by feldman＠MFSDatanet.COM 22 Oct '95

22 Oct '95

Please send me traceroutes and ping output showing the problems. Samples when things are working would also be good as a baseline. I'd like to see if we can correlate the problems to congestion on the shared FDDI, or if something's really broken. Steve

1 0