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 packet mode or byte mode is discussed further in [Floyd97].
So IMO (and based on the RFC 2309 text) an active queue
management recommendation that neglects "byte mode" and fails
to cite RFC 2309 as informative text would be omitting important
considerations that implementors should take into account.
The background paper, Floyd97, states that the assumption is that bandwidth is the scarce resource. This may very well be the case for the regular case of active queue management for packets that pass through the router. However, I do not think this is the case here -- the scarce resource should be assumed to be the pps of error messages generated by the router, in which case the byte mode is inappropriate.
Pekka,
Let's be clear first on what node you are referring to by "the router". Let's
assume node A sends packets to node B that causes B to send ICMPv6 error
messages to node C (where, A and C may/may not be the same nodes and/or
the network path A->B may/may not have similar congestion/bandwidth/delay
characteristics to the path B->C). The "router" in this case is node B - correct?
Assuming we are on the same page, 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 from B->C is uncongested and uses only fast links.
Threat model 2:
*************
The router is uncongested, but the network path from B->C is congested
and/or has low-bandwidth links.
The threat model here is assumed to be that an attacker forces the router to respond to packets with ICMP, overloading the CPU or other resources of the router.
This is threat model 1. This threat model applies to the "leading edge" of the router's algorithm for generating ICMPv6 errors, i.e., if the router knows a priori that local resources are too congested, it will selectively refrain from generating the error messages in the first place (i.e., using the rate limiting parameters B and B). But, if the constraining resources are available buffer space, it could well be that bytes (rather than number of packets) would be the more appropriate metric.
Again, the scarce resource could be the bandwidth in cases where the links are very low bandwidth, either close to the error-sending router or somewhere along the path -- but this is an issue which calls for strict AQM for all kinds of packets, and no special action should be needed for ICMPv6 error messages.
This is threat model 2. This threat model would apply to the "trailing edge" of the router's algorithm for generating ICMPv6 errors, i.e., if the router's local resources are uncongested it will generate the errors, forward them to the network for transmission, but will then have no way of knowing whether a congested/bandwidth-constrained link occurs on the path B->C (unless the congested link occurs on the 1st hop) and should therefore use AQM on ICMPv6 errors sent on the outgoing attached link.
I agree that this issue calls for AQM for all kinds of packets, and indeed this is well supported by the BCP documents. But, I disagree that no special action should be needed for ICMPv6 error messages. For example, suppose node X at the head of a slow link X->Y on the path from B->C is using AQM and operating near the queue's high water mark. If the traffic passing through X->Y is mostly due to well behaved sessions, a high arrival rate of ICMPv6 error messages from B at X will result in an equal likelihood of dropping the legitimate traffic as dropping the ICMPv6 messages. Also, we have only the BCP recommendations that network nodes implement AQM; we have no guarantees that network nodes along all forwarding paths will comply.
Finally, I have looked at the RED queue management documents at:
http://www.icir.org/floyd/red.htm
and so far I have not seen any conclusive evidence that shows either packet mode vs. byte mode as the clearly superior model. As such, I see it as beyond the scope of the document in question to promote one of the models over the other.
Thanks - Fred [EMAIL PROTECTED]
As such, I suggest the following:
A recommended method for implementing the rate-limiting
function is a token bucket, limiting the average rate of
transmission to N, where N can either be packets/second or a
fraction of the attached link's bandwidth, but allowing up to
B error messages/bytes to be transmitted in a burst, as long
as the long-term average is not exceeded. Other methods that
provide effective active queue management [RFC2309] for
outgoing ICMPv6 error messages are also acceptable.
I have to disagree here, on the grounds that it adds a bit complexity, and may confuse the reader because the reference to active queue management was written to talk about AQM of the forwarding path -- not error generation path -- and as may be misleading or inappropriate.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
