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.