operational: icmp echo out of control?

E.B. Dreger eddy+public+spam at noc.everquick.net
Tue May 28 19:17:32 UTC 2002


RAS> Date: Tue, 28 May 2002 14:43:25 -0400
RAS> From: Richard A Steenbergen


RAS> Theoretically, ICMP Echo should be less intrusive for
RAS> performance measuring since it is clearly only for this
RAS> purpose, whereas doing an actual TCP handshake could easily

And less accurate for asymmetric traffic, under-representing the
return flow.


RAS> be mistaken for a port scan. But for so many network admins,
RAS> all they know is "ICMP bad".

That'll be the day when someone calls abuse saying "I'm being
attacked by ICMP unreachables!" ;-)


RAS> Besides, if you thought ICMP was inaccurate, a TCP handshake
RAS> is far worse.  First, you have no way of knowing if the TCP
RAS> replies are the originals, or if they have been
RAS> retransmitted, so any single sample is pretty useless for
RAS> measuring reply time. Second, for most cases with TCP opens,
RAS> you are measuring the interaction time of the application
RAS> process, not response time from the kernel. Depending on how

Ah, yes.  Reminds me of the "benchmark" where a company that
writes mailserver software tested HELO response time.  Gee, my
MXen spend more time actually sending and receiving messages!


RAS> the application is written, and what event model it uses, it
RAS> is very likely to be doing other things before and after it
RAS> gets notified that there is a new connection, then does the
RAS> accept().

If it gets that far.  I suspect that accept filters would give
artificially fast results.

Then there are issues such as delayed ACK.  And if one is
measuring throughput, does the session ever make it past slow
start?  And just how many frames do they send during slow start?
(Tunable under FreeBSD...)

Once ECN becomes more common, does one consider those points
outliers or useful data?


RAS> Internet path measurement isn't simple, you're probably best
RAS> off trying to get as much data as possible passively. :)

Less intrusive, and chances are that anything too small for
statistical validity is insignificant, anyway.


--
Eddy

Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist at brics.com>
To: blacklist at brics.com
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist at brics.com>, or you are likely to
be blocked.




More information about the NANOG mailing list