(Sorry, this wound up in my probably-spam folder as it contained
HTML markups..)
On Thu, 15 Jan 2004, Sellers, Julian P wrote:
I think Pekka's rephrasing is good. (I would remove the word
additional.)
Yes, I agree additional is unnecessary there.
Pekka Savola [EMAIL PROTECTED] wrote:
On Wed, 14 Jan 2004, Sellers, Julian P wrote:
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
CMPv6 Rate Limiting Methods: Revised
Text (2)
Pekka Savola [EMAIL PROTECTED] wrote:
Let's rephrase this then, e.g:
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
From Pekka's text:
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
Of ext
Sellers, Julian P
Sent: Wednesday, January 14, 2004 2:47 PM
To: [EMAIL PROTECTED]
Subject: Re: ICMPv6 Rate Limiting Methods: Revised Text (2)
From Pekka's text:
One good way to implement the rate-limiting function
is a token
bucket, allowing up to B back
On Thu, 8 Jan 2004 [EMAIL PROTECTED] wrote:
Let me take my stab at trying the wording of this text:
=
(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
