operational: icmp echo out of control?

E.B. Dreger eddy+public+spam at noc.everquick.net
Thu May 23 20:58:13 UTC 2002


RAS> Date: Thu, 23 May 2002 16:36:23 -0400
RAS> From: Richard A Steenbergen

[ moderate snipping throughout ]


RAS> I can't speak as to what exactly Akamai is doing, but this
RAS> kind of probing for "performance" reasons is becoming
RAS> increasingly common as more people jump on the "optimized
RAS> routing" bandwagon.

Perhaps most maddening is that ICMP echo/response hardly reflects
real-world performance.  (At least I don't usually tunnel my
HTTP, SMTP, and FTP packets through ICMP, but perhaps I'm just
being weird again.)


RAS> Not only do you have operational networks originating these
RAS> probes on their own (InterNAP, Digital Island, Akamai,
RAS> others), but you now have companies making boxes which
RAS> "optimize routing" in part by doing these probes from every
RAS> one of their customers.

I'd hope that they're having the IP stack communicate timing info
to the apps.  The information is superior, and it doesn't require
any additional packets.


RAS> Path latency doesn't change much, you can determine this
RAS> with very few probes. Reachability does not need to be
RAS> continuously probed, you can take cues from other data to
RAS> decide if you need to re-probe. Packet loss cannot be
RAS> reliably determined without a lot more packets than it is
RAS> reasonable to send.


RAS> Much like web spidering, some simple common sense can help
RAS> keep probes from becoming a hassle:

Hmmmm.... anyone recall the number of the RFC that says many of
the same things?


RAS>  * If at all possible, only target destinations you actually
RAS>    exchange traffic with. For example, get a netflow feed.

Which, IMHO, is the sane way anyhow.  Why spend bandwidth and CPU
munching on a point that exchanges 0.00000001% of one's traffic?
It's silly.  Now, if it's an outlier that shows performance worse
than, say, 3 sigma slower than average, that might be another
story.


--
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