Also, there had been much discussion about how certain methods are lacking and should be omitted. I don't think any should be omitted - consider the possibility of combining all three methods to clamp the ICMP rate in different domains. In the presence of asymmetric bandwidth (consider ADSL), or asymmetric routing, the token bucket method can cause floods that would be prevented if the bandwidth method was used as an additional clamping mechanism.
Perhaps something like this should be mentioned in the text as well.
One other thing - "values greater than 20-30 might break traceroute" is stated with no explanation as to why, and it seems that 20-30 is an arbitrary number (with no explicit units) that will change in the future as bandwidth capacity increases. I agree with the sentiment of the statement, but think there should be some explanation as to how an implementor might compute this value (perhaps how the 20-30 was derived).
Zachary Amsden [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi All,
As I sensed after all the discussion we had, the WG will prefer to expand the text to prefer token-bucket method and describe the limitations of the other two. If my conclusion is wrong, feel free to scream :) Otherwise, here is the revised text.
Please review the text and let me know if we need to add/modify/correct anything. If you want something to be changed, please send me the new proposed text.
I couldn't decide what the correct default values of the parameters should be. So I haven't mentioned anything. If
anyone wants to add, please send me the values.
======================================================= (f) Finally, in order to limit the bandwidth and forwarding costs incurred sending ICMPv6 error messages, an IPv6 node MUST limit the rate of ICMPv6 error messages it sends. This situation may occur when a source sending a stream of erroneous packets fails to heed the resulting ICMPv6 error messages. There are a variety of ways of implementing the rate-limiting function, for example:
(f.1) Timer-based - for example, limiting the rate of transmission of error messages to at most once every T milliseconds.
(f.2) Bandwidth-based - for example, limiting the rate at which error messages are sent from a particular interface to some fraction F of the attached link's bandwidth.
(f.3) Token-bucket based - for example, allowing up to B back- to-back error messages to be transmitted in a burst, but limiting the average rate of transmission to N where N can either be packets/seconds or a fraction of the attached link's bandwidth.
The limit parameters (e.g., T, F, B and N in the above examples) MUST be configurable for the node.
Token-bucket based function should be preferrable over the other two.
If Timer-based or Bandwidth-based function is chosen because of the simplicity of implementation, proper care must be taken in choosing the value of T or F. Values of T that are higher than 20-30 might break traceroute. A global value of F per node might not be appropriate for all the links attached to the node. =======================================================
Regards Mukesh
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
