(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
: [EMAIL PROTECTED]Subject: RE:
ICMPv6 Rate Limiting Methods: Revised Text
On further thought, the key words in the entire section of text we are
talking
about are: "attached link's bandwidth". For interfaces that attach to the
global
Internet, the "attached link" is
On further thought, the key words in the entire section of text we are talking
about are: "attached link's bandwidth". For interfaces that attach to the global
Internet, the "attached link" is the Internet itself and can be viewed as a
variable-bandwidth link with a wide range of bandwidth
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,
Zachary Amsden wrote:
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.
I am reading that text in a different way, and I believe the way
in which it
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.
The text definitely looks better than mine. I will use the above
text.
Hi Zachary,
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
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
[EMAIL PROTECTED] wrote:
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
14 matches
Mail list logo
