On Mon, 16 Aug 2004, Fred Templin wrote:
In the case of logical (pt-to-pt) interfaces, actual per-source traffic measurements may be readily available. In such cases, why would an implementation use an aggregate estimator when it can easily compute actual per-source values for rate limiting??
I vote for the "SHOULD" option for per-interface rate limiting when per-source traffic measurements are available.
Are there any implementations doing this or interface-specific
limiting? None that I know of, but please enlighten us if so.
You've asked this question before, and you were given an answer.
This goes in circles.
Please check the references I pointed you to: LINUX and CISCO implementations of interface based ICMP rate control.
I don't think having such in a draft standard is acceptable.
It is about time to bring this spec where it should have been earlier.
On the other hand, node-based token bucket limiters are commonplace, and work without any perceived problems AFAICS even behind slow/fast interfaces, behind tunnels, etc. --
Nobody said token bucket does not work.
But token buckets are not employed per node in routers, the way you said in your previous messages. This is plain misinformation, and I think it is really doing no good.
Token buckets are employed per flow and per interface in routers. That is the common place.
why do we need to say more than that?
Because suggesting a token bucket rate control per node for a router with slow/fast interfaces is plain wrong.
It is time to make the appropriate correction to the spec.
If the specs says something about rate control, which it does, it has to be correct. It is correct for hosts, it must be corrected for routers.
smime.p7s
Description: S/MIME Cryptographic Signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
