On Mon, 23 Aug 2004, Alex Conta wrote: > Pekka Savola wrote: > > On Wed, 18 Aug 2004 [EMAIL PROTECTED] wrote: > > > >>I think everyone agrees that per-interface configuration > >>would be a perfect solution and will provide a fine grained > >>control to the user. Is there anyone who disagrees with > >>this ? (Pekka ??) > > > > > > My objection to this stems from the fact that an implementation which > > would like to do something like that is likely doing something wrong > > in the first place > > Traffic management in its very nature is linked to interfaces: its > functional components are dispersed among other protocol functional > components in a router's functional topology that start at an "ingress" > interface and ends at an "egress" interface. There is plenty of > documentation on this in IETF and elsewhere. > > A separation of ICMP rate limiting, which is a form of traffic > management, from interfaces goes against this very nature.
I don't disagree with traffic management being important, but the point is: *Managing traffic ICMP traffic which is not originated from the node in question is out of scope of this specification.* Therefore if you need such knobs for traffic management, that's fine, but out of scope of this spec, and don't belong here. > >(or something which is implementation-specific in > > any case, and doesn't need "IETF blessing" for their approach in any > > case), and I slightly disagree with per-interface configuration. > > > > With a protocol purist perspective - nothing wrong - there is the > suggestion that ICMPv6 should bless or address only ICMP rate limiting > that is implemented inside the ICMP protocol engine. > > The reality is that ICMP protocol does not have a rate limiting > mechanism of its own - ICMP message headers do not have any rate > limiting fields. Neither does UDP, TCP (in the sense that you can always send the packets even if the rate at which actual data is sent is adjusted based on congestion), or a hundred other protocols. Why should ICMP have somethnig like that then? > The latter - (B) above - is a choice for minimizing the number of > vertices in the node's internal functional topology, combined with > maximizing the operational capabilities of the node: it controls all > "send" traffic, as well as "send" ICMP traffic (both "originated" and > "in transit"). It is a common (cost effective) choice in modern router > implementations, and possible choice in software (host) implementations > (LINUX is known, but there may be others). As already discussed to death, "in transit" is an entirely different rate-limiting concept with different requirements, assumptions, and the place to specify it, than "origination by a protocol" rate-limiting. > As configuring is the same (CLIs hide implementation details), and the > effect is the desired ICMP rate limiting, the IETF spec should not be > preferential in its blessing. For all implementations I know of (Juniper, Cisco, Linux, BSD, ...) out there the configuration of ICMP origination rate-limiters and generic traffic management (e.g., ICMP limiter for transit traffic) is *not* the same. > > This could possibly be achived by changing "send" to "originate" > > elsewhere in the spec, and reword (f) to something like: > > > > The judgment of how good a spec is, should not be based on the ability > of the spec to serve/support one side of a debate - lack of support > triggered discussion of "send". > > The judgment is the abundant existence of architectures and (host and > router) implementations of the traffic management model (above) and the > abundant existence of hardware/software components to build it, and > ultimately their use in operational networks. Based on that: > > I am opposed to any rewording of the first 3 paragraphs of > Section 2.4 (f) of the ICMPv6 specifications, that would exclude "in > transit" ICMP traffic from the ICMPv6 scope, because it can break > current implementation compliance and being within the ICMPv6 scope, > with a particular effect on routers and hardware/software > implementations in network processors, which are components for routers. > It can also break operational capabilities of routers, and the reliance > of network operators on these capabilities, which are important for > managing traffic in networks. No, this wouldn't make any such implementations non-compliant. They would just implement something more, something that's out of scope from the spec. One could call that a bonus feature if you want :-). Believe me, this particular interpretation is not required for managing traffic in the networks. Generic rate-limiting features already required, those which are not dependent on ICMPv6, and need to be provided in any case. This is no place to do that work. So, your proposal seems to be looking at a way not to implement separate ICMP origination rate-limiters, just make do with the generic rate-limiters which have been set-up appropriately. That's not something we as the IETF want to recommend (IMHO), but as long as it does the job, it's still compliant with the spec AFAICS. > This includes opposition to the suggestion to use packets per second as > the ONLY metric for ICMPv6 rate limiting. > > Packets/second is not an accurate metric: packets are not equal in size. > Different packet sizes have different impact on processing resources, > and thus different impact on implementations. > > Bits/second is an accurate and widely recognized standard metric, > expressing link bandwidth/speed, or interface bandwidth/speed. It can be > easily used as it is, or translated into internal resource metrics (for > instance for memory, or internal bus) and should be the recommended metric. Pps the is only real useful metric in the context of traffic origination. It's the number of packets (not their size) which cause processing, and it's the number of packets (not their size) which freeze the forwarding (e.g., in flow-based architectures) when you get hit by a flood of a million or two packets per second. But again, this wouldn't make an implementation non-compliant, as token bucket w/ pps is just a recommended example. And there are good reasons why it's recommended, but implementations can diverge from that if they really want.. the IETF just doesn't need to recommend 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 --------------------------------------------------------------------
