I've only been to one IETF but wasn't the IPPM (IP porvider metric) group working on just such a problem? Basically attacking how we measure performance on an internet? Did the group come up with anything? I deal with people every day that *insist* that pinging a router (yes, we're talking Cisco's in this case) is "a good enough indication for me" that "your routers are dropping X% of my packets". Sometimes it turns out to be true and I find the problem. Many times, it's just not so. That begs the question: How do I determine whether or not I have packet loss or delay on my network (and be able to prove it beyond a reasonable doubt)? Does FTPing a 50M file across the network tell me? Does a 10,000 packet ping tell me? My point for interjecting here is to ask: Has anyone come up with *any* way to measure network performance (packet loss, throughput, delay) other than ping and traceroute? I understand Mike's comments on defining *what* we really want to measure and I'm all for trying to help define it. I ask these questions because I'd really like to find answers, not to stir the coals even more. -brett
by all means, ping all you like. please do realize that routers have other things to do besides answer pings when they're busy. just because a router doesn't respond to 15% of its pings doesn't mean that it's dropping 15% of its packets or that there is a 15% loss on a line. router load is not router load, process switched packets are not the same as card-level switched or cache switched.
there aren't any easy answers. perhaps we should all just implement "ping" servers in pops ( a 386 running linux or bsd might suffice).
Jeff Young young@mci.net
On Sat, 21 Oct 1995, Mike O'Dell wrote:
remember that using pings to sample connectivity to a very busy cisco router is not a very reliable probe for several reasons. Returning pings is a low-priority task in the first place, and they are rate-limited, so if the processor is busy processing lots of BGP updates and several folks are fribbling with it using ping or SNMP, it is less than clear what they will see.
-mo
Michael A. Nasto quips:
OK! Agreed. So then, what would you use?
Have you ever been in a classroom and had a student raise his hand, answer every question, ask intelligent questions, etc. just to prove to the class how smart he or she is. This is the premise of the 'Two Mike's Interchange' above. One says, HEY! I know ping packets are a lower priority than everything else in a *CISCO* router LOOK AT ME (wave wave). Then another kid in the class quips... if PING is not what you would use, give us a better utility.
In fact... EVERYONE ( okay 99.73 percent :-) uses PING. After all router LOAD is router LOAD.... and if a few ICMP packets can't get back in a subjectly reasonable time.. then DUH.... "da network is busy......" BGP updates take bandwidth just like any other packet.
Of course the 0.27 percent, zen routing gods of the universe just feel the load and the harmonic BGP update patterns and PING between the BGP updates.... for a better answer.
Sorry, I could not resist.... and apologize for the satire. PING!! PING!! PING!!
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 */ | +--------------------------------------------------------------------------+
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
In message <199510230144.VAA22194@carbon.cary.mci.net>, "Brett D. Watson" write s:
My point for interjecting here is to ask:
Has anyone come up with *any* way to measure network performance (packet loss, throughput, delay) other than ping and traceroute?
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. In the absence of LQM we have the DS3 MIB (poor substitute) and ping for the FDDI rings (difficult to get any accuracy even with routes that can respond very quickly to pings). There are a ton of counters for packets lost on the router itself (for various values of "the router") that are thought to be accurate for congestion loss. For FDDI, usually packets not transmitted on the ring indicate the ring has been too busy, but this is used more a trouble warning. Curtis ps - as you suggest, maybe some linux or bsdi boxes are appropriate where the routers are unable to reliably return pings.
We, being interested in web services, test if we can establish a tcp connection to port 80.
Has anyone come up with *any* way to measure network performance (packet loss, throughput, delay) other than ping and traceroute?
-- (313) 741-4442 http://branch.com/ Jon Zeeff Branch Internet Services Inc. jon@branch.com *** WWW Hosting Services, WWW Site Development and the Branch Malls ***
participants (4)
-
Brett D. Watson -
Curtis Villamizar -
jon＠branch.com -
Mike O'Dell