Brian,
Based on the analysis in my last message, I also agree with Pekka.
But, I would still prefer to see the rate limiting text include the term
messages/bytes instead of just messages. If it is too complicated
I'm just not seeing it; if it is problematic, that is a different story.
I'm
Pekka,
Sorry for the delayed response, but I've been off pondering this one.
It seems to me that the question is more of a philisophical/operational
nature and not readily tackled from a theoretical perspective. The
point comes down to whom do you trust? Do you trust hosts to be
well behaved, or
On Mon, 19 Jan 2004, Fred Templin wrote:
[...]
Assuming we are on the same page,
Yep.
there are two worst-case threat
models to consider:
Threat model 1:
*
Node B (i.e., the router) is congested in terms of CPU load, memory
utilization, etc, while the network path
On Sun, 18 Jan 2004, Fred Templin wrote:
===
(f) Finally, in order to limit the bandwidth and forwarding costs
incurred sending ICMPv6 error messages, an IPv6 node MUST limit
the rate of ICMPv6 error messages it sends.
Fred,
I mostly agree with Pekka here.
Specific comments inline:
I think we may have glossed over this in earlier discussion,
but I believe
'B' should be allowed as an expression of either messages OR bytes.
Size *does* matter in certain cases, and expressing 'B'
only in terms
of a
Pekka Savola wrote:
On Sun, 18 Jan 2004, Fred Templin wrote:
===
(f) Finally, in order to limit the bandwidth and forwarding costs
incurred sending ICMPv6 error messages, an IPv6 node MUST limit
the rate of ICMPv6 error
[EMAIL PROTECTED] wrote:
I agree with Pekka that this compllicates the text and the
implementation. Moreover, N (the long-term average) can be
in number of packets per seconds or a fraction of the attached
link's bandwidth. Don't you think, the size of the packet
will be covered if N is
On Mon, 19 Jan 2004, Fred Templin wrote:
Note: the decision whether or not to drop an incoming packet
can be made in packet mode, ignoring packet sizes, or in
byte mode, taking into account the size of the incoming
packet. The performance implications of the choice between
Pekka Savola wrote:
On Mon, 19 Jan 2004, Fred Templin wrote:
Note: the decision whether or not to drop an incoming packet
can be made in packet mode, ignoring packet sizes, or in
byte mode, taking into account the size of the incoming
packet. The performance implications of the
Here is the final revision of the text that everyone seems to agree
upon. I will put this in the draft. Please let me know if anyone has
anymore comments on this.
===
(f) Finally, in order to limit the bandwidth and forwarding costs
Mukesh,
See comments below:[EMAIL PROTECTED] wrote:
Here is the final revision of the text that everyone seems to agree upon. I will put this in the draft. Please let me know if anyone has anymore comments on this. === (f) Finally, in order to
11 matches
Mail list logo