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 PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
