On Sun, 18 Jan 2004, Fred Templin wrote:
> > ===================================================
> > (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".
Fine by me, even though it's weaker.
> > 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".
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".
> > 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:
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.
> > 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"?
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
