No worries; I also had a mistake in my earlier messages when I failed to
mention the active queue management for last-hop routers in front slow links
recommended by the RFC 3150 BCP. (I don't know if the recommendation
extends to the case of the slow link occurring somewhere in the *middle*
of the
Hi
IPv6 WG added this work into the current work list.
- Update IPv6 over PPP (RFC2472) and publish
(may be done in PPP Extension w.g.).
Could somebody let me know what I-D is for this work ?
I failed in finding it both IPv6 w.g. and PPPEXT w.g.
Best wishes...
Daniel (Soohong Daniel Park)
M
Oops !! stupid
mistake of mine :)
The number of
packets from A to B will be limited by the thin link and
thus
B won't have to send
ICMP back at a higher rate.
Regards
Mukesh
-Original Message-From: Gupta Mukesh
(Nokia-NET/MtView) Sent: Wednesday, January 07, 2004 4:19
PM
Fred,
Rethinking about the following example of yours. Do we need to
consider
the
asymmetric paths between A and B ? I guess, the problem can be
seen
with even
symmetric path. Let say the network is
like
A <---
1gig ---> C <--- 56 kbps --> D <--- 1 gig --->
B
Now A
starts sending s
Mukesh,
As Pekka already pointed out, all the three methods are provided
as examples. The draft mandates the rate limiting by saying:
"an IPv6 node MUST limit the rate of ICMPv6 error messages it sends"
and then it provides examples by saying:
"There are a variety of ways of implementing the rat
> I'm worried about the same thing -- and I don't think source-based
> token-bucket is justified. Sure, feel free to do so, but a regular
> one should work just as well with sufficiently large burst allowance
> (e.g., 50-100 packets).
>
> If someone is DoS'ing you it may actually be a feature tha
(Tailed down the cc:)
On Wed, 7 Jan 2004, Fred Templin wrote:
> >Why not limit the rate of ICMPv6 error messages to a particular
> >source by using even the token-bucket based method ?
>
> I would be concerned about the overhead for caching per-source
> information, especially in low-end routers
Mukesh,
[EMAIL PROTECTED] wrote:
Fred,
I don't quite understand why the Timer-based method need to
consider the source but Token-bucket based method or the
Bandwidth-based method don't (as the draft suggests).
The text says:
(f.1) Timer-based - for example, limiting the rate of
Fred,
I agree that the parameters do matter and should be chosen
wisely.
As the methods are being listed as examples, the draft
can only "suggest" suitable values and can not mandate them.
I think, even Pekka agrees that we could provide some hint
to the implementors by listing some suitable val
Fred,
I don't quite understand why the Timer-based method need to
consider the source but Token-bucket based method or the
Bandwidth-based method don't (as the draft suggests).
Why not limit the rate of ICMPv6 error messages to a particular
source by using even the token-bucket based method ?
R
Hi Margaret,
> I'm not sure if these are logical reasons, but... I am
> concerned about making a change that will invalidate any
> existing ICMPv6 implementations, unless that change is
> absolutely necessary (e.g. to block a serious security
> hole or to prevent a significant operational problem
Pekka,
Mostly agree, except with the final paragraph where you say that
the parameters for token bucket, timer, etc. mechanisms don't
matter that much. ICMPv6 says that errors should include up to
the IPv6 min-MTU bytes of the packet that caused the error. That's
1280 bytes, but on some long, thi
Teemu,
ICMPv6 echo request/reply don't count, because they're not ICMPv6 errors.
If a well-behaved A is sending packets that cause B to generate ICMPv6 errors,
A will adapt its behavior and the ICMPv6 messages from B to A will naturally
subside. Can B be reasonably assured that A will be well beh
Margaret,
On further consideration, I think the bandwidth-based method might actually
be dangerous in some situations. Suppose there were asymmetric paths
between nodes A and B; the path A->B consisting of all 1Gbps links and
the path B->A consisting of at least one long, thin link (56Kb modem, 3
On Wed, 7 Jan 2004, Brian Haberman wrote:
> > I think that would appropriately encourage implementation of
> > the Token-bucket method without invalidating existing
> > implementations that use one of the others.
>
> I agree with the sentiment here. Changes to this document should
> not affect ba
Margaret Wasserman wrote:
Hi Mukesh,
One of the issues raised was about rate limiting methods
suggested by the draft. The draft suggests Timer-based,
Bandwidth-based and Token-bucket based methods for limiting
the rate of the ICMP messages.
After going through the discussion about this in the a
Hi,
I have a question/clarification about the Token-bucket based method I couldn't clearly
figure out from draft or mail discussions I found.
If there is a situation like this:
- Node A is already sending loads of ICMPv6 to the Node B for any reason (Node B
flooding A with echo requests for ex
17 matches
Mail list logo
