On Mon, 16 Aug 2004, Alex Conta wrote:
You may have an assumption that the rate-limiting would have to be a
percentage of the interface speed. That's (IMHO) a bad strategy,
exactly why you describe: it doesn't handle fast/slow interfaces
appropriately.
This is a misinterpretation. Essentially I am saying that identical rate-limiting parameters (N,B in draft terms) on slow/fast interfaces would not handle ICMP traffic appropriately.
Depends on what you want to achieve with the rate-limiting.
I pointed you to the LINUX and CISCO examples. I expect to achieve nothing different than the LINUX and CISCO implementers/users expect.
The one sentence text suggested for the ICMP specs suggesting a higher threshold for a good router ICMP implementation, similar to LINUX or CISCO helps the implementers. This means also consistency, since brings the router ICMP implementation on the same threshold as the host ICMP implementation.
If you want to make sure that ICMP responses don't eat up all of a very slow link (e.g., 64 kbit/s), a single parameter might not be sufficient, yes.
But my point is that we shouldn't be overly concerned about this. That kind of very slow interfaces will need some kind of queuing, rate-limiting, etc. mechanisms to be usable in any case. *)
The main point is to create a reasonable upper bound for the amount of ICMP packets generated, so that you don't generate an ICMP error out of potentially every packet.
Rate limiting is well understood. Using the token bucket for rate limiting means simply using a better shaper than a timer based, or straight bandwidth limiting shaper.
But please stop for a moment to consider the example default token bucket values: N=10: that would result in the maximum of 4 kbit/s of generated ICMP traffic (double this when bursting). Even if you used N=100 (which would be sufficient even with 10 Gbit/s interfaces), you would have the maximum the maximum of 40 Kbit/s of ICMP traffic.
Saying that one token bucket per node is sufficient, you're either not understanding of how token bucket shapers are used, or you're stretching
the characteristics of the token bucket mechanism, making it appear
something which is not.
N = 1000 packet/sec average in mathematical abstraction is similar to 1packet/msec, but in terms of links that have different speed/bandwidth it is very far from meaning the same thing.
B = 1000 packet/sec maximum burst does not mean the same thing and does not have the same impact relative to a T1, and relative to a 1G interface.
It is one of the reasons traffic management is using multiple token buckets in a node, in fact multiple token bucket per interface.
Is this *REALLY* too much message generation? Something that makes it worth to *specify* interface-specific values, make implementations check the interfaces where the packets would be destined to go out to, implement some logic to use for virtual interfaces, etc.? Doesn't look like that to me. Seems like unnecessary complexity to me.
The implementation in LINUX and CISCO seem to suggest differently.
On the other hand I am open - in fact I suggested text - to make the SHOULD conditional to the existence of per interface traffic shaping.
If you really, really think this is needed, and the WG agrees with that, I'd suggest we put interface-specific values as a MAY --
Using MAY does not bring anything and therefore does not make sense. A MAY would be useful if there were a list of restrictions, to specify one or two restrictions that a router could make exception to.
definitely not a SHOULD.
SHOULD is not a MUST; it is a suggested feature, not mandated feature. If an implementation does not have it, it does not mean it is not compliant.
(However, you could limit the upper bound for token bucket based on the interface speed, I guess.)
Rephrasing your statement using draft parameters terminology, that is, N=average rate of transmission, and B=upper bound of transmission,
you're agreeing that Bx for a slow interface "X" should be different than Bz for a fast interface "Z".
No, I don't really agree with that. I think B shouldn't need to be varied based on the interface speed. [...]
You're contradicting yourself from one message to another...
I think I understand: you are opposed because you are opposed...
Following this dialog, from your starting with a concern of two implementations, to moving to something else, every time your concern, or problem is answered or responded, makes it quite clear.
Regards, Alex
smime.p7s
Description: S/MIME Cryptographic Signature-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
