On Tue, 17 Aug 2004, Alex Conta wrote: > > Depends on what you want to achieve with the rate-limiting. > > I pointed you to the LINUX and CISCO examples. I expect to achieve > nothing different than the LINUX and CISCO implementers/users expect. > > The one sentence text suggested for the ICMP specs suggesting a higher > threshold for a good router ICMP implementation, similar to LINUX or > CISCO helps the implementers. This means also consistency, since brings > the router ICMP implementation on the same threshold as the host ICMP > implementation.
Those were examples of *generic* rate-limiters. No-one is doing rate-limiting of ICMP generation like that (because those would have to be configured by the users, and those will not just restrict ICMP generation, but ICMP forwarding etc as well). The ICMP rate-limiters are done as part of the ICMP implementation itself. For example on Linux, look at something like icmpvX_xrlim_allow in the kernel source under net/ipv4 or net/ipv6/. Or if you want a Cisco example how to configure this, check out 'ipv6 icmp error-interval' -command. I think you're confused about what kind of rate-limiting is being specified in the ICMP spec. > > 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. > > Saying that one token bucket per node is sufficient, you're either not > understanding of how token bucket shapers are used, or you're stretching > the characteristics of the token bucket mechanism, making it appear > something which is not. > > N = 1000 packet/sec average in mathematical abstraction is similar to > 1packet/msec, but in terms of links that have different speed/bandwidth > it is very far from meaning the same thing. > > B = 1000 packet/sec maximum burst does not mean the same thing and does > not have the same impact relative to a T1, and relative to a 1G interface. > > It is one of the reasons traffic management is using multiple token > buckets in a node, in fact multiple token bucket per interface. We're not discussing rate-limiting of ICMP in general, just discussing the number of ICMP messages the node is allowed to generate on its own. (The point above!) A single limiter certainly wouldn't be sufficient if you wanted to limit e.g., the ICMP traffic the node is forwarding, but that's definitely out of scope of this specification! > > 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. > > > > The implementation in LINUX and CISCO seem to suggest differently. > > On the other hand I am open - in fact I suggested text - to make the > SHOULD conditional to the existence of per interface traffic shaping. Again, that's a *generic* rate-limiting example. That's not the point and is out of scope for *ICMP generation* rate-limiter. > > 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 -- > > Using MAY does not bring anything and therefore does not make sense. A > MAY would be useful if there were a list of restrictions, to specify one > or two restrictions that a router could make exception to. MAY makes a note to the implementors to be wary, but does not require anything. This is the maximum we should be doing, and I'd argue we don't want even that. -- 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 --------------------------------------------------------------------
