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

From: [email-masked]
Date: Mon, 5 Jan 2004 19:25:03 -0600

Hi All,

I have taken the responsibility of being the editor for
the draft draft-ietf-ipngwg-icmp-v3-02.txt and I am trying
to address the issues raised by Thomas.

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.

Regards
Mukesh
PS: Here are the snippets from the archive just to refresh
everyone.

Thomas Narten:
=========
T= 0.5 seems fairly high. Why not .1 or .01 (on today's links).

It might also be useful to point out that having too much rate
limiting (in routers) causes problems for traceroute, since this has
been experienced in practice. Indeed, if routers rate limit to one
message every .5 seconds, today's traceroute would seem to become
unusable in practice. Indeed, even at .1 seconds, traceroute won't
hardly work anymore. I.e., the first probe will get trigger an ICMP
error, the second one (some 20-30 ms later) will not, due to rate
limiting, etc.

Would it be better to move away completely from fixed time intervals
and just say as a percentage of the link traffic? at least in the case
of routers?
=========

Pekka Savola:
=========
Well, I brought up the issue with traceroute when I noticed some major 
router vendors implemented timer-based mechanisms, and proposed the 
token-bucket mechanism (which is used quite often).

Personally, I'm a bit unsatisfied how the examples are portrayed; IMO, 
timer-based should definitely go away, be put in last, huge disclaimers 
printed or whatever.

Bandwidth-based does not really scale: same implementation could be used 
over 64kbit/s or 10Gbit/s links.  What's the percentage there?  Assuming 
sending ICMP errors require processor cycles, the latter might still use 
up too much CPU even with 0.01% ;-) 

Also personally, token bucket is IMO the only sensible way to handle this.
=========

Robert Elz:
=========
It should be revised, but should be specified as token bucket type
specifications - that is, it should be possible to send a burst of
ICMPs if they're needed, just as long as the long term rate doesn't
get above N (N can be pkts/sec, or percentage of packets processed).

The link traffic percentage model (alone) breaks down if there has been
no traffic (N% of 0 is 0, no matter what N is).

Make all rate limits be specified with a rate/second (and 2/sec, or T=0.5)
as a nice conservative default (just default) I can handle, but with a
burst count of about 20 (as dedfault) (10 seconds with none, and 20 can
be sent very quickly again).
=========

Francis Dupont:
=========
I agree because T should be in milliseconds (f.1) and
is against back-to-back erroneous packets. I propose 20ms (50Hz).
=========

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 06 Jan 2004 09:33:57 +0100

In your previous mail you wrote:

=> Even if Token-based is the best method it can be a bit expensive
to implement (code size and memory requirements) on very small devices
so I am not convinced we should remove simpler methods... IMHO the
Timer-based method with proper parameters (i.e., one ICMP per tick
with a 50Hz clock) should be kept. Note that very small devices are
not router in general (and never core routers, cf traceroute concerns).

Regards

[email-masked]

PS: this topics seems more a v6ops one, doesn't it?

---

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Jan 2004 11:17:47 +0200 (EET)

> not router in general (and never core routers, cf traceroute concerns).

I have to disagree here.  Even if a very small device was not a
router, it would have to respond to traceroutes etc., even though with
lower probability that multiple ones would be happening
simultaneously.  But still, if e.g. a "dumb" host is connected to a
network, and someone close by (e.g. 3-4 hops) sends a traceroute, the 
packets could be sent e.g. 1 ms apart.  Any timer-based mechanism is 
inappropriate, unless it has some kind of "burst allowance", which was 
what Robert Elz also argued for -- but that's token-based filter just 
with different words.

So, I'd say, keep only token-based filter as an example, but if it
seems important one could explain, e.g. in an appendix, why
timer/bandwidth -based mechanisms aren't sufficient on their own.  In
any case, I believe it's important to document that being able to send
the packets in burst is an important characteristic of the filter.

> PS: this topics seems more a v6ops one, doesn't it?

The operational requirements (traceroute, etc.), yes, but this is 
being revised at this WG so it should probably be OK..

-- 
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: Francis Dupont <[email-masked]>
Date: Tue, 06 Jan 2004 11:08:35 +0100

=> it seems you are confusing ping and traceroute: even a (too) stupid
rate-limiting device is never a problem on the target of a traceroute
because when one'd like to test reachability one uses ping (with the
standard one second delay between probes).

=> IMHO traceroute is not the good argument here.

   
=> this is an operational issue so the requirements should come from
the v6ops WG and then we could see if token-based method should be made
mandatory. Because today the only argument we have is for rate-limitation
using any reasonable method.

Regards

---

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Jan 2004 13:19:26 +0200 (EET)

> standard one second delay between probes).

Even the target of the traceroute replies with ICMP unreachables.

13:16:09.430527 192.88.99.1 > 80.186.174.139: 2001:670:86:3001::1.58692 > 2002:50ba:ae8b::1.33434: udp 16 [hlim 1]
13:16:09.430806 80.186.174.139 > 192.88.99.1: 2002:50ba:ae8b::1 > 2001:670:86:3001::1: icmp6: 2002:50ba:ae8b::1 udp port 33434 unreachable
13:16:09.464535 192.88.99.1 > 80.186.174.139: 2001:670:86:3001::1.58692 > 2002:50ba:ae8b::1.33434: udp 16 [hlim 1]
13:16:09.464726 80.186.174.139 > 192.88.99.1: 2002:50ba:ae8b::1 > 2001:670:86:3001::1: icmp6: 2002:50ba:ae8b::1 udp port 33434 unreachable
13:16:09.494352 192.88.99.1 > 80.186.174.139: 2001:670:86:3001::1.58692 > 2002:50ba:ae8b::1.33434: udp 16 [hlim 1]
13:16:09.494545 80.186.174.139 > 192.88.99.1: 2002:50ba:ae8b::1 > 2001:670:86:3001::1: icmp6: 2002:50ba:ae8b::1 udp port 33434 unreachable

So, if such a dumb box is the target of traceroute, an "asterisk" does
appear if the limiting is not implemented properly, i.e. there is no 
allowance for the bursts.

> using any reasonable method.

If it's not enough that at least one member of v6ops says traceroute
is a must, and rate-limiting must take that into an account, one could
take the thread there explicitly.. depending on how formally that
would be done it might cause none or a lot of delay.

---

From: Fred Templin <[email-masked]>
Date: Tue, 6 Jan 2004 07:38:59 -0800 (PST)

Pekka,
 
Asterisks already appear all the time using 'traceroute'. That is why
three responses are solicited from each hop and the process proceeds
to the next hop even if only one response is received. (Indeed, many of
the traceroutes I have seen will "knock three times" repeatedly when a
non-responsive hop is encountered.)
 
I agree that the traceroute example is a weak one, and not sufficient
reason to exclude valid implementation alternatives.
 
Fred
[email-masked]

Pekka Savola <[email-masked]> wrote:
So, if such a dumb box is the target of traceroute, an "asterisk" does
appear if the limiting is not implemented properly, i.e. there is no 
allowance for the bursts.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Jan 2004 19:43:33 +0200 (EET)

> non-responsive hop is encountered.)

Right.  But in my opinion, we want to optimize for the case that we 
don't have to fall back to the timeouts unnecessarily.  Multiple 
seconds' delay at each misbehaving hop is inappropriate.
  
> reason to exclude valid implementation alternatives.

We'll just have to disagree on this.  Internet traffic is
characteristically rather bursty.  The rate-limitng functions have to
be able to deal with that.