Its important to note a point entioned here that vendors are building boxes to do this as well. I ran a 3dns pair for a while and wow the mail that came in from people with firewalls or simply watching for probes. F5 was opening all sorts of half opened connections and wierd ports other than ones involving dns. I believed they called it iquerry. On Thu, 23 May 2002, E.B. Dreger wrote:
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@brics.com> To: blacklist@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@brics.com>, or you are likely to be blocked.