North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Initial Route Server Stats for MAE-East

  • From: Brett D. Watson
  • Date: Sun Oct 22 22:20:32 1995

  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
> [email protected]
> 
> > 
> > > 
> > > 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 */ | 
> > +--------------------------------------------------------------------------+
>