Subject: ICMPv6 Rate Limiting Methods: Revised Test (final ??)

From: [email-masked]
Date: Sun, 18 Jan 2004 14:24:38 -0600

Here is the final revision of the text that everyone seems to agree
upon. I will put this in the draft. Please let me know if anyone has
anymore comments on this.

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

        One good way to implement the rate-limiting function is a token
        bucket, limiting the average rate of transmission to N, where N
        can either be packets/second or a fraction of the attached
        link's bandwidth, but allowing up to B error messages to be
        transmitted in a burst, as long as the long-term average is not
        exceeded.

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

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: Sun, 18 Jan 2004 15:23:07 -0800 (PST)

Mukesh,
 
See comments below:

> anymore comments on this.
 
Something about the phrase: "One good way" seems a bit unusual
to appear in standards documents; I prefer something like:
"A suggested method".

>         transmitted in a burst, as long as the long-term average is not
 
I think we may have glossed over this in earlier discussion, but I believe
'B' should be allowed as an expression of either messages OR bytes.
Size *does* matter in certain cases, and expressing 'B' only in terms
of a number of messages is too limiting. I think this can be fixed rather
simply by changing the phrase: "B error messages" to
"B error messages/bytes".

>         milliseconds (even with low values for T), is not reasonable.
 
I don't see the purpose in dis-recommending a particular scheme,
(i.e., the simple timer), since there are infinitely many other
possibilities that would be equally bad (or worse). Suggest
shortening this paragraph to a single sentence such as:
 
   "Rate-limiting mechanisms which cannot cope with bursty traffic
   (e.g., traceroute) are not recommended."

>         small/mid -sized device, the possible defaults could be B=10,
 
I may have missed this in earlier discussion, but the "SHOULD"
above used to be a "MUST" in the earlier text - is there any reason
we are now saying "SHOULD" instead of "MUST"?
 
Also, I no longer see the value in listing possible default values for
B/N. Since B/N can be used to represent either packets or bytes,
simple scalar values like "10" have no meaning. Suggest dropping
the entire sentence beginning: "For example, in a...".
 
Fred L. Templin
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Jan 2004 09:26:45 +0200 (EET)

> to appear in standards documents; I prefer something like:

Fine by me, even though it's weaker.

> "B error messages/bytes".

I don't think is a good idea.  This complicates the text, and for most 
implementations, counting the error bytes doesn't really make sense.  
In addition, this is still a suggestion or "one good way".

> shortening this paragraph to a single sentence such as:

IMHO, it makes sense to dis-recommend an approach, because it's
actually deployed out there, and thus it seems to be a good idea to
specifically say that it is NOT a good idea.  I'm not aware of other, 
"really broken" mechanisms which would have been deployed.  Moreover, 
this was suggested in the previous RFC, so recommending against it 
explicitly seems like a good idea.  

The text could use a bit sharpening up, to say that timer-based 
discouragement is just and example, though, like:

       Rate-limiting mechanisms which cannot cope with bursty traffic
        (e.g., traceroute) are not recommended; for example, a simple
        timer-based implementation, allowing an error message every T
        milliseconds (even with low values for T), is not reasonable.
  
> we are now saying "SHOULD" instead of "MUST"?

I thought that was appropriate due to the reasons listed in the mail
where I proposed the text.  I do not think it makes sense to require
the values MUST be configurable on every kind of device -- take e.g. a
mobile phone which implements an IPv6 stack.  MUST seems too strong
here.  SHOULD seems more appropriate.  Changing the values is
typically very useful especially in the cases where the implementation
may be used in small devices and bigger routers as well.

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

---

From: Fred Templin <[email-masked]>
Date: Mon, 19 Jan 2004 06:50:34 -0800

>Fine by me, even though it's weaker.

OK; how about: "A recommended method for implementing...".

Fred
[email-masked]