On Mon, 16 Aug 2004, Alex Conta wrote: > > You may have an assumption that the rate-limiting would have to be a > > percentage of the interface speed. That's (IMHO) a bad strategy, > > exactly why you describe: it doesn't handle fast/slow interfaces > > appropriately. > > This is a misinterpretation. Essentially I am saying that identical > rate-limiting parameters (N,B in draft terms) on slow/fast interfaces > would not handle ICMP traffic appropriately.
Depends on what you want to achieve with the rate-limiting. If you want to make sure that ICMP responses don't eat up all of a very slow link (e.g., 64 kbit/s), a single parameter might not be sufficient, yes. But my point is that we shouldn't be overly concerned about this. That kind of very slow interfaces will need some kind of queuing, rate-limiting, etc. mechanisms to be usable in any case. *) The main point is to create a reasonable upper bound for the amount of ICMP packets generated, so that you don't generate an ICMP error out of potentially every packet. But please stop for a moment to consider the example default token bucket values: N=10: that would result in the maximum of 4 kbit/s of generated ICMP traffic (double this when bursting). Even if you used N=100 (which would be sufficient even with 10 Gbit/s interfaces), you would have the maximum the maximum of 40 Kbit/s of ICMP traffic. Is this *REALLY* too much message generation? Something that makes it worth to *specify* interface-specific values, make implementations check the interfaces where the packets would be destined to go out to, implement some logic to use for virtual interfaces, etc.? Doesn't look like that to me. Seems like unnecessary complexity to me. If you really, really think this is needed, and the WG agrees with that, I'd suggest we put interface-specific values as a MAY -- definitely not a SHOULD. > > (However, you could limit the upper bound for token > > bucket based on the interface speed, I guess.) > > > > Rephrasing your statement using draft parameters terminology, that is, > N=average rate of transmission, and B=upper bound of transmission, > you're agreeing that Bx for a slow interface "X" should be different > than Bz for a fast interface "Z". No, I don't really agree with that. I think B shouldn't need to be varied based on the interface speed. Just picking a sufficiently large value, e.g., 10, 20, 50 or 100 should allow sufficient amount of ICMP generation on fast interfaces, while still not generating too much of it with slow interfaces. Please remember that to be usable, very slow interfaces need more generic rate-limiters as well (compare to your reference to particular implementations e.g., Linux, earlier on this thread). That's orthogonal to this limiter. Hence, we shouldn't need to make a "perfect" ICMP generation limiter, which would be sufficient on its own even in the fringe cases, but just a "good enough" ICMP generation limiter. (See the paragraph above marked with *). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
