Subject: ICMPv6 Rate Limiting Methods: Revised Text

From: [email-masked]
Date: Thu, 8 Jan 2004 18:08:36 -0600

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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Templin <[email-masked]>
Date: Thu, 08 Jan 2004 18:31:04 -0800

>        not be appropriate for all the links attached to the node.

Small change suggestion for the second sentence of the above paragraph:

   Values of T that are higher than 20-30 might break legitimate
   functionality that requires timely delivery of ICMPv6 error
   messages (e.g., traceroute), while smaller values might cause
   saturation of slow links.

I'm also not entirely sure about your cautions regarding "a global
value of F per node"; the text of f.2 says: "limiting the rate at which
error messages are sent from a particular interface to some fraction
F of the attached link's bandwidth" - it doesn't say anything about
a global value of F for the node.

Thanks - Fred
[email-masked]

---

From: Zachary Amsden <[email-masked]>
Date: Fri, 09 Jan 2004 12:46:32 -0800

It seems to me that "back to back" is ill-defined.  It is highly 
unlikely that the ICMP error packets will be transmitted with no other 
transmissions in between, which "back to back" seems to imply.  The 
burst allowance should probably be defined as "allowing a burst of N 
packets over Ts seconds", or something along these lines.

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-masked]

---

From: Zachary Amsden <[email-masked]>
Date: Fri, 09 Jan 2004 12:06:07 -0800

Zachary Amsden
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Fri, 09 Jan 2004 15:36:27 -0800

Zachary Amsden wrote:

> transmissions in between, which "back to back" seems to imply.

I am reading that text in a different way, and I believe the way
in which it was originally intended. The text says: "back to back
_error_ messages"; it is not intended to imply that there will
be no other packet transmissions in between the ICMPv6 error
packets.

The rate of ordinary packet transmissions, and whether/not the
ordinary packets may be interleaved between the ICMPv6 error
packets comprising the burst, has no relevance for B.

Fred
[email-masked]

> 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.
>
> 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 
>> 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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 13 Jan 2004 20:36:13 +0200 (EET)

On Thu, 8 Jan 2004 [email-masked] wrote:

Let me take my stab at trying the wording of this text:

=====
        to heed the resulting ICMPv6 error messages.

        One good way to implement the rate-limiting function is a token
        bucket, 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.

        Rate-limiting mechanisms which cannot cope with bursty traffic
        (e.g., traceroute) are not recommended; thus a simple timer-based
        implementation, allowing an error message every T 
        milliseconds (even with low values for T), is not reasonable.

        The rate-limiting parameters SHOULD be configurable.  In the case
        of a token-bucket implementation, the best defaults depend on where
        the implementation is expected to be deployed (e.g., a high-end 
        router vs. an embedded host).  For example, in a small/mid -sized
        device, the possible defaults could be B=10, N=10/s.
=====

Reasoning: 
 - RFC1918 states rate-limiting SHOULD be configurable.  A MUST seems 
too heavy in case the implementation and the defaults have been chosen 
properly.

 - Pure bandwidth-based mechanism doesn't seem to be useful at all, so 
for simplicit, omit it from here (can be coupled with a token bucket 
still).

 - It's rather difficult to recommend good values for B and N, as
different kinds of nodes may have entirely different deployment
scenarios.  I don't feel particularly strongly on this, just invented
some values which would probably be OK for all but the biggest
routers.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings