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 examples 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 at 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
--------------------------------------------------------------------
