RED: Discussions of Setting Parameters Sally Floyd, from a November 1997 email message. >Are there generally agreed upon rules for setting RED parameters? For >instance, if a backbone provider has a cross-country 155 mbit link, >what values should it use for buffer space, min_th, max_th, max_p, and >w_q? First the easy ones: ------------------------------------------- max_th: Short Summary: Set max_th to three times min_th. The Reason: The 1993 RED paper recommends setting max_th to at least twice min_th. My current rule of thumb is to set max_th to three times min_th. ---------------------------------------------------- max_p (the upper bound on the marking probability p): Short Summary: Set max_p to 0.1. The Reason: The 1993 RED paper didn't say much about max_p, and the simulations in that paper set max_p to 0.02. This reflected a completely unrealistic view of what "typical" congestion levels would be like, and was based on my assumption that, when things were working correctly, steady-state packet drop levels at a router would not be more than 2%. It has been clear for some time now that end-to-end steady-state packet drop rates for a flow can be more than 5%. It seems possible that congestion can be sufficiently high, composed of very many very small connections, that even with RED, steady-state packet drop rates of 5% would not be unusual at a router. Thus, the default in the ns-2 simulator is now to set max_p to 0.1, and that would be my recommendation. In my view, there is no need to set max_p to anything higher than 0.1. If a router is operating with steady-state packet drop rates of 20-30%, then I assume that something is wrong in the engineering of the network, and that this is not the region that anyone wants to optimize. -------------------------------------------------------- Now for the harder ones, the ones that don't have definite answers. From the 1993 RED paper: "The RED gateway allows conscious design decisions to be made about the average queue size and maximum queue size allowed at the gateway." There is no way around the fact that these are conscious design decisions, that the **optimal** values for these are not known, and that the **optimal** values would depend on a wide range of factors including not only the link speed and propagation delay, but the traffic characteristics, level of statistical multiplexing, and such, for the traffic on that link. These decisions about average and maximum queue size are embodied not only in the choice of buffer size, but also in the choice for min_th and w_q. One factor to take into account is how many packets are likely to arrive at the queue in a "typical" roundtrip time (assuming that there is such a thing...). For congestion that lasts less than a "typical" roundtrip time, the ideal behavior would be for the queue to absorb this congestion, without dropping packets. For congestion that lasts longer than a "typical" roundtrip time, the ideal behavior would be for the estimated queue size to begin to reflect this congestion, and for the router to begin to give feedback to the end nodes. ---------------------------------------------------------- min_th: Short Summary: Set min_th to five packets? Reasons: The optimal setting for min_th depends on exactly what the desired tradeoff is at that router between low average delay and high link utilization. In the ns-2 simulator, min_th is set to a default of 5 packets (or, for a queue measured in bytes rather than packets, 5 packets times some configured mean-packet-size in bytes). The burstier the traffic arrival process, the higher min_th would have to be to achieve a given average link utilization. The optimal setting for min_th also depends partly on the link speed, propagation delay, and maximum buffer size. For min_th and max_th set to 5 and 20 packets respectively, does this correspond to a queueing delay in seconds that is trivial compared to the transmission and propagation delay of the link? If so, then there is probably no reason not to set min_th and max_th higher. I can't think of any scenario where it would be a good idea to set min_th as small as one or two packets - setting min_th too small means that you aren't allowing for much burstiness in the arrival process. --------------------------------------------------------- w_q: Short Summary: Set w_q to 0.002? Reasons: The 1993 RED paper recommends setting w_q to at least 0.001. The ns-1 and ns-2 simulators set w_q to a default of 0.002. The choice of w_q determines the "time constant" (roughly speaking) for the averaging for the average queue size. If w_q is too low, then the estimated average queue size is probably responding too slowly to transient congestion. If w_q is too high, then the estimated average queue size too closely tracks the instantaneous queue size. Sections VI.A. and VI.B. of the 1993 RED paper give quantitative quidelines for w_q, in terms of the size of the transient burst that the queue can accomodate without dropping any packets at all. Thus, the min_th is five packets, and it is desired to allow a transient burst of a queue of up to 50 packets without dropping any packets at all, then w_g has to be less than 0.0042. Section VI.B. also gives the quantitative relationship between w_q and the "time constant" of the averager. -------------------------------------------------------- Results from actual implementations: If anyone has experiences to report, from actual implementations, of viable ranges for RED parameters, I would be happy to report them here. floyd@ee.lbl.gov.