- Test - lists.nanog.org

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

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

22 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

Re: Initial Route Server Stats for MAE-East
by feldman＠MFSDatanet.COM 21 Oct '95

21 Oct '95

One potential problem is that rs1 gets to nearly everyone else, including the Gigaswitch, through the shared FDDI ring. The shared FDDI is now hitting 85 Mbps 5-minute averages during peak times. Steve > From list-admin(a)merit.edu Fri Oct 20 17:58:19 1995 > To: "William B. Norton" <wbn(a)merit.edu> > Cc: Curtis Villamizar <curtis(a)ans.net>, nanog(a)home.merit.edu > Reply-To: curtis(a)ans.net > Subject: Re: Initial Route Server Stats for MAE-East > In-Reply-To: Your message of "Fri, 20 Oct 1995 14:33:51 EDT." > <Pine.SUN.3.91.951020142813.25539B-100000(a)home.merit.edu> > Date: Fri, 20 Oct 1995 20:35:24 -0400 > From: Curtis Villamizar <curtis(a)ans.net> > > > In message <Pine.SUN.3.91.951020142813.25539B-100000(a)home.merit.edu>, "William > B. Norton" writes: > > > > Thanks for the feedback Curtis. You are correct that one might get the > > wrong impression. ( Our intent here was really to show the layout of the > > web page and get some feedback, and this ANS router just happened to be > > first.) Dun just uploaded all the rest of the MAE-East Peer delay/packet > > loss graphs. Thanks for the suggestion. > > > > Web Pointer to MAE-East graphs: http://www.ra.net/~ra/statistics > > > > Bill & Dun > > > Bill, > > Could you tell us a little more about your packet loss sampling? Like > how many ping packets are you using per collection point? > > If those packet loss statistics at the Mae are correct, we have some > serious trouble there. I just fired up a ping to .181 on the ring > (MCI) and in 100 packets lost 2 (close together - I saw the sequence > numbers that were missing). I tried again with 1000 and got 0 loss. > Maybe it's just an off time. Still I can't see how you could be > approaching anything near 10-20% on all the major providers. You've > got some nasty peaks there. > > My first inclination was to wonder if you overflowed the space for UDP > packets by kicking off two much data collection on the RS at once. We > used to lose SNMP replies for that reason when we kicked off two may > GETs at 15 minute intervals. We'll be looking at this too to try to > confirm the loss you are reporting. > > Curtis >

1 0