Subject: RE: ICMPv6 Rate Limiting Methods: Revised Text

From: [email-masked]
Date: Fri, 9 Jan 2004 18:11:14 -0600

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 
> packets over Ts seconds", or something along these lines.

I agree with Fred's explaination about this one. We could make it even
clearer by adding word "ICMP" before error messages.

====
... allowing up to B back-to-back ICMP error messages to be ...
====

Is that going to help ??

> Also, there had been much discussion about how certain methods are 
> lacking and should be omitted.  I don't think any should be omitted - 
> consider the possibility of combining all three methods to clamp the 
> ICMP rate in different domains.  In the presence of asymmetric bandwidth 
> (consider ADSL), or asymmetric routing, the token bucket method can 
> cause floods that would be prevented if the bandwidth method 
> was used as an additional clamping mechanism.
>
> Perhaps something like this should be mentioned in the text as well.

How about we add the following text with the line which says that the
token-bucket based functions should be preferred.

=====
A combination of more than one functions can also be used if required.
=====

> One other thing - "values greater than 20-30 might break traceroute" 
> is stated with no explanation as to why, and it seems that 20-30 is an 
> arbitrary number (with no explicit units) that will change in 
> the future as bandwidth capacity increases.

point (f.1) describes that the unit of T is milliseconds.

I had copied number 20-30 from an old mail of Thomas Narten where he
described how the Timer-based functions will break traceroute. This
is the time between 2 probes of traceroute. Does anyone has a better
view of what this number should be ? If not, do you think, we should
not put this number and just say that higher values of T might break
traceroute ??

Regards
Mukesh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------