Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods

From: Margaret Wasserman <[email-masked]>
Date: Tue, 06 Jan 2004 21:06:21 -0500

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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 07 Jan 2004 06:35:39 -0500

> implementations that use one of the others.

I agree with the sentiment here.  Changes to this document should
not affect backwards compatability.  So, I would be opposed to
making the proposed change unless we can determine that noone has
implemented the timer-based or bandwidth-based mechanisms.

Regards,
Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 7 Jan 2004 14:03:18 +0200 (EET)

> implemented the timer-based or bandwidth-based mechanisms.

Timer-based methods have, unfortunately, been implemented and
deploying.  IMHO, those should definitely be changed, but I have some
sympathy for those who see this as something like "yeah, it's broken,
but we don't care about this strongly enough to make them fix it."

Remember that in the current text, we're talking about *examples* of 
possibilities to implement the rate-limiter.  We'd just be removing 
bad examples, and probably adding some non-normative text on why 
token-based mechanism is recommended.

This might be a different situation if we said that token-based 
rate-limiting MUST be implemented.. but at least I'm not arguing for 
going that far.

As for the different values of token-bucket (or timer-based, or 
whatever) mechanisms, I'm not sure if that matters that much, it could 
be an implementation detail as long as it's reasonable.  At most one 
could give a "SHOULD be at least XXXX" implementation hint..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Templin <[email-masked]>
Date: Wed, 7 Jan 2004 05:32:24 -0800 (PST)

Margaret,
 
On further consideration, I think the bandwidth-based method might actually
be dangerous in some situations. Suppose there were asymmetric paths
between nodes A and B; the path A->B consisting of all 1Gbps links and
the path B->A consisting of at least one long, thin link (56Kb modem, 3GPP
wireless, etc.) Even if B is able to authenticate the source addresses in
packets it receives from A, if the bandwidth-based method is used based
on a percentage of the bandwith of B's outgoing 1Gbps interface the queue
on a router at the head of a long thin link on the path B->A will overflow. In
other words, B might cause harmful denial-of-service if it blindly uses a
bandwidth-based estimate, since it has no way of knowing whether long,
thin links will occur on the return path.
 
As to timer-based, I think Mukesh has already given a good reason as to
why it is suboptimal; I think an arguement could also be constructed that
shows it to cause interoperability problems in some cases. So, I find
myself in the rare position of agreeing with Pekka on this subject.
 
Fred
[email-masked]  

Margaret Wasserman <[email-masked]> wrote:

Hi Mukesh,

Thoughts?

Margaret

---

From: Fred Templin <[email-masked]>
Date: Wed, 7 Jan 2004 06:13:03 -0800 (PST)

Pekka,
 
Mostly agree, except with the final paragraph where you say that
the parameters for token bucket, timer, etc. mechanisms don't
matter that much. ICMPv6 says that errors should include up to
the IPv6 min-MTU bytes of the packet that caused the error. That's
1280 bytes, but on some long, thin links the store-and-forward time
for such a large packet can be on the order of 1 second! (Remember
also the asymmetric path case I referred to in a previous message.)
 
So, it seems to me that it does matter that suitible values are chosen
for the parameters - am I wrong?
 
Fred
[email-masked]

Pekka Savola <[email-masked]> wrote:

---

From: Yasuhiro Ohara <[email-masked]>
Date: Fri, 09 Jan 2004 07:13:10 +0900 (JST)

Hi, only roughly going through this thread but ...

> thin links will occur on the return path.

Only being dangerous in some situations do not necessarily mean that
it should be deleted completely. If there's still cases where the
feature can be used sufficiently, the feature should survive, No ?

regards,
yasu