On Thu, Aug 28, 2003 at 08:48:50AM -0400, Jared Mauch wrote:
they [customers] expect a bit of loss when transiting a peering circuit or public fabric, and if the loss is only of icmp they tend to not care.
Um, since when? My customers expect perfection and if they don't get it, they're gonna gripe. Even if it's just the appearance of a problem (through traceroute and ICMP echo or similar), I'm going to hear about it. Personally, I tollerate a little loss. But I'm an engineer. I'm not a customer who has little or no concept of how the internet works and who doesn't really want to. The customer just wants it to work and when it doesn't they expect me to fix it, not explain to them that there really isn't a problem and that it's all in their head.
What are other transit providers doing about this or is it just GLBX?
here's one of many i've posted in the past, note it's also related to securing machines.
http://www.ultraviolet.org/mail-archives/nanog.2002/0168.html
I recommend everyone do such icmp rate-limits on their peering circuits and public exchange fabrics to what is a 'normal' traffic flow on your network. The above message from the archives is from Jan 2002, if these were a problem then and still are now, perhaps people should either 1) accept that this is part of normal internet operations, or 2) decide that this is enough and it's time to seriously do something about these things.
While rate limiting ICMP can be a good thing, it has to be done carefully and probably can't be uniform across the backbone. (think of a common site that gets pinged whenever someone wants to test to see if their connection went down or if it's just loaded.. Limit ICMP into them impropperly and lots of folks notice.) Such limiting also has to undergo periodic tuning as traffic levels increase, traffic patterns shift, and so forth. If a provider is willing to put the effort into it to do it right, I'm all for it. If they're just gonna arbitrarily decide that the allowable flow rate is 200k across an OC48 and never touch it again then that policy is going to cause problems. --- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/