RE: ICMPv6 Rate Limiting Methods: Revised Text

[Bound, Jim]

Title: Message

Folks,

 

Interesting discussion.  I agree with Fred and his line of logic and that just leave all three in tact and all will work for different conditions and why they are there.  We have no need to pull any of the options out for rate-limiting.  If some one wants to add one or enhance one then that is a different matter and subject.  Suggest sending with specific case in the subject line.

 

/jim

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fred Templin
Sent: Saturday, January 10, 2004 9:29 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: ICMPv6 Rate Limiting Methods: Revised Text

On further thought, the key words in the entire section of text we are talking

about are: "attached link's bandwidth". For interfaces that attach to the global

Internet, the "attached link" is the Internet itself and can be viewed as a

variable-bandwidth link with a wide range of bandwidth possibilities based

on the return path to a particular source node to which the ICMP error

messages will be sent.

 

The bandwidth of a return path to a particular source node is determined

by the slowest physical link encountered at any hop along the path, and

I believe we can expect to see physical links as slow as 10Kbps in wide

deployment for the forseeable future. So, any rate limiting parameters we

recommend would need to limit the ICMPs to an acceptably-low bandwidth

below 10Kbps when the node sending the ICMPs cannot determine the

bandwidth of the return path to the source of packets causing the errors.

 

In order to send ICMP messages at both and effective and safe rates, nodes

that send the ICMPs would need to determine the bandwidths of the return

paths to the sources of packets causing errors. Because the growing trend

toward path asymmetry gives us no guarantee that the bandwidths in both

directions will be the same (or even similar), the bandwidths of the return paths

can only be determined by direct measurement, This also implies that nodes

that generate ICMPs would need to keep per-source state information and

(since the bandwidth along a particular path may vary over time) repeat the

bandwidth measurements periodically.

 

The inevitable conclusion of all of this is that nodes that do not maintain

state and do not have a means for determining the bandwidth along the

return paths to source nodes will not be able to determine when it is OK

to send ICMP error messages without the possibility of causing harmful

congestion. Or, if they do decide to send ICMP error messages anyway,

will need to do so at a rate that is acceptable for the worst-case bandwidth

for any physical links that might occur in the Internet. In the case of

physical links as slow as 10Kbps, such an acceptable rate would be

far too low to provide any useful benefit in most cases.

 

Fred L. Templin

[EMAIL PROTECTED]

[EMAIL PROTECTED]

[EMAIL PROTECTED] wrote:

> Values of T that are higher than 20-30 might break legitimate
> functionality that requires timely delivery of ICMPv6 error
> messages (e.g., traceroute), while smaller values might cause
> saturation of slow links.

The text definitely looks better than mine. I will use the above
text.

> I'm also not entirely sure about your cautions regarding "a global
> value of F per node"; the text of f.2 says: "limiting the
> rate at which
> error messages are sent from a particular interface to some fraction
> F of the attached link's bandwidth" - it doesn't say anything about
> a global value of F for the node.

The line "The limit parameters (e.g., T, F, B and N in the above examples)
MUST be configurable for the node." implies that F is configured as a
global value for the node. What I wanted to poi! nt out was that if the admin
was allowed to configure the value of F per interface, we will not have
the scalability problem that Pekka had pointed out. (we will still have
the problem in asymmetric path topology that you described).

I would be happy to put any text that will describe the limitations of the
bandwidth-based method in a better way ?

Regards
Mukesh

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