[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Section 2.4, item (f) of draft-ietf-ipngwg-icmp-v3-04.txt

Pekka Savola wrote:
> 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
>>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 

> 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.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6