[EMAIL PROTECTED] wrote:
Fred,
I don't quite understand why the Timer-based method need to consider the source but Token-bucket based method or the Bandwidth-based method don't (as the draft suggests).
The text says:
(f.1) Timer-based - for example, limiting the rate of
transmission of error messages to a given source, or to
any source, to at most once every T milliseconds.The key phrase is: "to a given source, or to any source", so it doesn't seem that the timer-based method *needs* to consider the source. BTW, I cut-and-pasted the above text out of RFC 1885 (published in December 1995 and obsoleted by RFC 2463) so we are talking about very old history here.
Why not limit the rate of ICMPv6 error messages to a particular source by using even the token-bucket based method ?
I would be concerned about the overhead for caching per-source information, especially in low-end routers. But, that's just an off-the-cuff remark and not well thought out in terms of all the implications.
Fred [EMAIL PROTECTED]
Regards Mukesh
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext Fred Templin Sent: Wednesday, January 07, 2004 6:00 AM To: Savolainen Teemu (Nokia-TP/Tampere); [EMAIL PROTECTED] Subject: RE: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods
Teemu,
ICMPv6 echo request/reply don't count, because they're not ICMPv6 errors. If a well-behaved A is sending packets that cause B to generate ICMPv6 errors, A will adapt its behavior and the ICMPv6 messages from B to A will naturally subside. Can B be reasonably assured that A will be well behaved if B has a security association with A? I certainly think so. Must B maintain state to avoid the problem you are describing for any A with which it does not have a security association? Perhaps.
Under the assumption of well-behaved nodes, Pekka's point about token bucket being well-suited for bursty traffic was a good one; once the burst of messages from A causing B to send errors subsides, other nodes such as C will receive the ICMPv6 error messages they need from B so that they can also naturally adapt their behavior.
Fred [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote: Hi,
I have a question/clarification about the Token-bucket based method I couldn't clearly figure out from draft or mail discussions I found.
If there is a situation like this: - Node A is already sending loads of ICMPv6 to the Node B for any reason (Node B flooding A with echo requests for example).
- Node C sends something to Node A that causes ICMPv6 message to be sent to Node C
- Now wouldn't Node A very likely drop the single response for Node C because Node B has already caused A's Token-bucket to fill up and over? Wouldn't this be a bit unfair for Node C, particularily if the Node B is deliberately flooding A?
So should Token-bucket based method also look for source/destination address like Timer-based method says? Or is this fully implementation specific issue as the draft states that those three methods (f.1/f.2/f.3) are example! s anyway?
Thanks,
Teemu
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext Margaret Wasserman Sent: 07 January, 2004 04:06 To: Gupta Mukesh (Nokia-NET/MtView) Cc: [EMAIL PROTECTED] Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods
Hi Mukesh,
One of the issues raised was about rate limiting methods suggested by the draft. The draft suggests Timer-based, Bandwidth-based and Token-bucket based methods for limiting the rate of the ICMP messages.
After going through the discussion about this in the archive and thinking about this a little bit, I propose that we remove the Timer-based and Bandwidth-based methods and just keep the Token-bucket based method in the draft. (look at the arguments a! t the end of this mail)
I would like to hear from people who would like to keep the
Timer-based and Bandwidth-based methods with logical reasons.
I'm not sure if these are logical reasons, but... I am concerned about making a change that will invalidate any existing ICMPv6 implementations, unless that change is absolutely necessary (e.g. to block a serious security hole or to prevent a significant operational problem).
Would it work to state in the new draft that implementations SHOULD implement the Token-bucket method, but MAY implement the other methods?
I think that would appropriately encourage implementation of the Token-bucket method without invalidating existing implementations that use one of the others.
Thoughts?
Margaret
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
