Mukesh,
See comments below:
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
> 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
> 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
Something about the phrase: "One good way" seems a bit unusual
to appear in standards documents; I prefer something like:
"A suggested method".
> 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.
> 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.
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".
> 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.
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."
> 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.
> 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.
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
