October 1995 - Test - lists.nanog.org

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 22 Oct '95

22 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 22 Oct '95

22 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 21 Oct '95

21 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 21 Oct '95

21 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 21 Oct '95

21 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 21 Oct '95

21 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

Re: MAE-East
by Scott Bradner 21 Oct '95

21 Oct '95

Like Ran, I get most of my connectivity through MAE-East. I also find quite large packet loss across MAE-East during most of east-coast prime time. I also see total outages of a few min duration, sometimes a number of them per hour (this could be the route flap Ran mentioned) traceroute stops at MAE-East during these times. Scott

1 0

MAE-East
by atkinson＠itd.nrl.navy.mil 21 Oct '95

21 Oct '95

As one whose packets generally go to the rest of the world via DREN/MAE-East (except when DREN decides to black hole the packets at NCCOSC in San Diego; ugly comments about idiots who use IGRP as IGP in a backbone with cycles and about the same idiots who think IGRP is an EGP deleted here), I'd like to note that I see a couple of kinds of problems far too regularly at MAE-East. The first problem is high packet loss (most usually during US East Coast regular business hours; I try to avoid work at other times, not always successfully). The second problem is route flapping (most usually between nodes in the icp.net domain). Route flapping has not been as much of a problem for me personally as the packet loss has been. Methinks that MAE-East would benefit from additional examination by the folks who look after it to see if my personal experience reflects personal bad luck or whether their might be an actual fixable problem there. Regards, Ran rja(a)cs.nrl.navy.mil

1 0

WITHDRAWN: Motion for Post NSF AUP
by Tim Bass 21 Oct '95

21 Oct '95

The motion I put forward for creating a draft AUP is withdrawn. The objections to methods, words, groups, definitions, ideas, opinions, and general noise seem to outweight the constructive comments and suggestions. Thanks you, everyone, who provided constructive comments, encouragement and suggestions. The other comments were just an example of what spam really is, IMHO :-) 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 */ | +--------------------------------------------------------------------------+

2 1