Subject: RE: ICMPv6 Rate Limiting Methods: Revised Text

From: [email-masked]
Date: Fri, 9 Jan 2004 17:48:36 -0600

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

---

From: Fred Templin <[email-masked]>
Date: Sat, 10 Jan 2004 06:28:30 -0800 (PST)

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

Regards
Mukesh