Subject: RE: ICMPv6 Rate Limiting Methods: Revised Text

From: "Bound, Jim" <[email-masked]>
Date: Sun, 11 Jan 2004 17:21:07 -0500

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-masked] [mailto:[email-masked]] On Behalf
Of Fred Templin
	Sent: Saturday, January 10, 2004 9:29 AM
	To: [email-masked]
	Cc: [email-masked]
	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-masked]
	[email-masked]

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

---

From: Fred Templin <[email-masked]>
Date: Mon, 12 Jan 2004 17:16:56 -0800

Hello,

Based on the concensus that appears to be emerging from the
"ICMPv6 Rate Limiting Methods: Revised Text" thread, it
seems to me (please correct me if I am wrong) that there is
no real compelling reason to make any changes to the existing
text of section 2.4 (f) found in the current document:

  http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-02.txt

However, I believe that in order to avoid interoperability issues while
allowing maximum flexibility, some additional text is needed at the
end of that section to specify operational requirements for setting rate
limit parameter values. I would like to propose the following (the 1st
paragraph already appears in the current document; the 2nd and 3rd
paragraphs are new):

   The limit parameters (e.g., T or F in the above examples) MUST
   be configurable for the node, with a conservative default value
   (e.g., T = 0.5 second, NOT 0 seconds, or F = 2 percent, NOT 100
   percent).

   Nodes MUST NOT configure limit values that would permit
   sustained error rates high enough to monopolize a 10Kbps link
   over any interface attached to the global Internet - either directly,
   or through a gateway that does not implement rate limiting. (The
   10Kbps value reflects the worst-case link speed anticipated along
   any potential path in ther Internet.)

   Nodes that keep extra state information MAY maintain per
   (interface/source) limit values. Nodes that also dynamically
   measure the bandwidth along return paths to specific sources
   MAY maintain dynamic per source limit values based on the
   measured bandwidths, rather than 10Kbps.

Comments?

Fred
[email-masked]

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 13 Jan 2004 20:08:09 +0200 (EET)

>    measured bandwidths, rather than 10Kbps.

I really don't understand this specific "overloading" concern.

You can equally ping a router with 1500 byte packets, and the 
responses will be 1500 bytes in size.  There is no rate-limit for such 
messages.  Designing for this kind of "vastly different capacities in 
each direction" just don't seem to be worth considering here.

-- 
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: Tue, 13 Jan 2004 11:37:21 -0800

Pekka Savola wrote:

 > Designing for this kind of "vastly different capacities in

I have to disagree; I believe there is a clear need to design
for diverse link bandwidths to support near-term deployments
and to foster future innovation.

10Kbps seems the best value for LCD, given commonly-deployed
links that will see continued use into the future (see BCP
documents produced by the PILC working group). 10Kbps also
provides the useful characteristic that it is the bandwidth
required to realize a 1 second delay budget for transmitting
a 1280 byte packet.

Would be interested to hear other opinions on this.

Fred L. Templin
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 14 Jan 2004 21:38:59 +0200 (EET)

Hi,

> and to foster future innovation.

There is a different perspective to supporting near-term deployments 
and fostering innovation..
 
> documents produced by the PILC working group). 

.. that is, restricting mechanisms based on the least common
denominator of Internet does not cut it. As we have up-to 10 Gbit/s
links in our network, why again we should limit our use of resources
to 10 Kbit/s? :-)

One should note that such very constrained environments, like 10
Kbit/s, have to restrict the traffic somehow in any case -- for 
example, provide the rate-limiting at the edge of such a link.

That is, I don't think solving the problem of restricting traffic to
fit into these restricted links belongs in this specification.

---

From: Fred Templin <[email-masked]>
Date: Thu, 15 Jan 2004 05:25:42 -0800 (PST)

> links in our network, why again we should limit our use of resources
 
No; not seeking to constrain high-speed links based on LCD at all.
But, the important point that you seem to be agreeing with is that
there will be a wide diversity of link bandwidths in the Internet both
now and into the future.  

> example, provide the rate-limiting at the edge of such a link.

I must agree on this point as being well supported by the BCP
documents. The active queue management recommendation for
forwarding nodes in front of slow links seems particularly important.
 
Fred L. Templin
[email-masked]