Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??)

2004-01-28 Thread Fred Templin
Brian, Based on the analysis in my last message, I also agree with Pekka. But, I would still prefer to see the rate limiting text include the term messages/bytes instead of just messages. If it is too complicated I'm just not seeing it; if it is problematic, that is a different story. I'm

Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??)

2004-01-23 Thread Fred Templin
Pekka, Sorry for the delayed response, but I've been off pondering this one. It seems to me that the question is more of a philisophical/operational nature and not readily tackled from a theoretical perspective. The point comes down to whom do you trust? Do you trust hosts to be well behaved, or

Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??)

2004-01-22 Thread Pekka Savola
On Mon, 19 Jan 2004, Fred Templin wrote: [...] Assuming we are on the same page, Yep. there are two worst-case threat models to consider: Threat model 1: * Node B (i.e., the router) is congested in terms of CPU load, memory utilization, etc, while the network path

Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??)

2004-01-19 Thread Pekka Savola
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.

RE: ICMPv6 Rate Limiting Methods: Revised Test (final ??)

2004-01-19 Thread Mukesh . Gupta
Fred, I mostly agree with Pekka here. Specific comments inline: 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

Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??)

2004-01-19 Thread Fred Templin
Pekka Savola wrote: 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

Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??)

2004-01-19 Thread Fred Templin
[EMAIL PROTECTED] wrote: I agree with Pekka that this compllicates the text and the implementation. Moreover, N (the long-term average) can be in number of packets per seconds or a fraction of the attached link's bandwidth. Don't you think, the size of the packet will be covered if N is

Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??)

2004-01-19 Thread Pekka Savola
On Mon, 19 Jan 2004, Fred Templin wrote: Note: the decision whether or not to drop an incoming packet can be made in packet mode, ignoring packet sizes, or in byte mode, taking into account the size of the incoming packet. The performance implications of the choice between

Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??)

2004-01-19 Thread Fred Templin
Pekka Savola wrote: On Mon, 19 Jan 2004, Fred Templin wrote: Note: the decision whether or not to drop an incoming packet can be made in packet mode, ignoring packet sizes, or in byte mode, taking into account the size of the incoming packet. The performance implications of the

ICMPv6 Rate Limiting Methods: Revised Test (final ??)

2004-01-18 Thread Mukesh . Gupta
Here is the final revision of the text that everyone seems to agree upon. I will put this in the draft. Please let me know if anyone has anymore comments on this. === (f) Finally, in order to limit the bandwidth and forwarding costs

Re: ICMPv6 Rate Limiting Methods: Revised Test (final ??)

2004-01-18 Thread Fred Templin
Mukesh, See comments below:[EMAIL PROTECTED] wrote: Here is the final revision of the text that everyone seems to agree upon. I will put this in the draft. Please let me know if anyone has anymore comments on this. === (f) Finally, in order to