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

From: [email-masked]
Date: Wed, 7 Jan 2004 11:54:18 -0600

Fred,

I agree that the parameters do matter and should be chosen
wisely.

As the methods are being listed as examples, the draft
can only "suggest" suitable values and can not mandate them.

I think, even Pekka agrees that we could provide some hint
to the implementors by listing some suitable values in the
draft.

Regards
Mukesh

-----Original Message-----
From: ext Fred Templin [mailto:[email-masked]]
Sent: Wednesday, January 07, 2004 6:13 AM
To: Pekka Savola; Brian Haberman
Cc: Margaret Wasserman; Gupta Mukesh (Nokia-NET/MtView); [email-masked]
Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods

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:
On Wed, 7 Jan 2004, Brian Haberman wrote:
> > I think that would appropriately encourage implementation of
> > the Token-bucket method without invalidating existing
> > 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.

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: [email-masked]
Date: Wed, 7 Jan 2004 13:01:47 -0600

> I'm worried about the same thing -- and I don't think source-based
> token-bucket is justified.  Sure, feel free to do so, but a regular
> one should work just as well with sufficiently large burst allowance
> (e.g., 50-100 packets).
> 
> If someone is DoS'ing you it may actually be a feature that you don't 
> consider the source .. you can't overload the box by spoofing 
> different source addresses :-)

Makes sense :)

> W.r.t. the other thread, I don't have objections to giving an 
> implementation hint on the parameters -- it's just that I don't think 
> it's really needed.

If we were to provide such a hint, what would be the suitable values
for B and N ??

(allowing up to B back-to-back error messages to be transmitted in a 
burst, but limiting the average rate of transmission to N messages
per second.)

Regards
Mukesh

---

From: [email-masked]
Date: Wed, 7 Jan 2004 18:19:11 -0600

Fred,
 
Rethinking about the following example of yours. Do we need to consider
the asymmetric paths between A and B ? I guess, the problem can be seen
with even symmetric path. Let say the network is like
 
A <--- 1gig ---> C <--- 56 kbps --> D <--- 1 gig ---> B
 
Now A starts sending some packets and B generates ICMPv6 error 
messages. If B is using bandwidth-based function for limiting the rate,
it would calculate the percentage using 1 gig link's bandwidth and will 
overload the thin link between C & D.
 
Am I missing something ?
 
Regards
Mukesh

-----Original Message-----
From: ext Fred Templin [mailto:[email-masked]]
Sent: Wednesday, January 07, 2004 5:32 AM
To: Margaret Wasserman; Gupta Mukesh (Nokia-NET/MtView)
Cc: [email-masked]
Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods

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
 <mailto:[email-masked]> [email-masked]