M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. In Proc. of 7th Int. Workshop on Quality of Service (IWQoS '99), London, pages 260--262, June 1999.  Home/Search   Document Details and Download   Summary   Related Articles   Check

.... Therefore, IETF has recommended RED as the single active buffer management for wide deployment in the Internet[36] However, the setting of RED parameters has proved to be highly sensitive to network scenarios and the performance of misconfigured RED may suffer significantly [14] 37] [38]. Therefore, RED needs constant tuning to adapt to the prevailing network conditions. In view of this, it has been debated whether or not RED can achieve its claimed advantages[38] 39] 40] Based on simplified models, some general guidelines for setting RED parameters have been proposed[35] ....

....be highly sensitive to network scenarios and the performance of misconfigured RED may suffer significantly [14] 37] 38] Therefore, RED needs constant tuning to adapt to the prevailing network conditions. In view of this, it has been debated whether or not RED can achieve its claimed advantages[38], 39] 40] Based on simplified models, some general guidelines for setting RED parameters have been proposed[35] 37] 41] Intuitive modifications on RED have also been proposed to automate the tuning of RED under varying network conditions by adjusting one of the parameters[14] 42] ....

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. Technical report, INRIA Sophia-Antipolis, France, 1999.

.... DropTail[2] Therefore, IETF has recommended RED as the single active queue management for wide deployment in the Internet [3] However, the setting of RED parameters has proved to be highly sensitive to network scenarios and the performance of misconfigured RED may suffer significantly [4] 5] [6]. In addition, since network is a dynamic system, RED needs constant tuning to adapt to current network conditions. In view of this, it has been debated whether or not RED can achieve its claimed advantages[6] 7] 8] This paper attempts to address the following questions: Given a network ....

....scenarios and the performance of misconfigured RED may suffer significantly [4] 5] 6] In addition, since network is a dynamic system, RED needs constant tuning to adapt to current network conditions. In view of this, it has been debated whether or not RED can achieve its claimed advantages[6], 7] 8] This paper attempts to address the following questions: Given a network scenario, how to optimally configure RED parameters . Given varying network conditions, how to dynamically tune RED to the optimal setting . When optimally configured, can RED effectively control ....

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. Technical report, INRIA Sophia-Antipolis, France, 1999.

....Also by introducing the randomization, we avoid burst losses, thereby making the loss events distributed . This then helps in solving the problem of phase effects. Though RED can introduce randomization in networks to some extent, it is not widely deployed due to variety of reasons [10], 11] In this paper, we propose a modification to TCP, called Randomized TCP, as a mechanism for introducing randomization into the network. In Randomized TCP, instead of sending back to back packets, the packet sending times are randomized. Specifically, successive packets of a window are sent ....

M. May, J. Bolot, C. Diot and B. Lyles, "Reasons not to deploy RED," Proc. of IWQoS, pp. 260-262, London, UK, June 1999.

....in faster recovery from transmission losses. Despite the importance of AQM, the actual mechanisms proposed have mostly been built on heuristics to achieve their goals. Even though most AQMs significantly improve on these goals, they often need manual tuning or provide only slow convergence [3] [5] The recent introduction of Explicit Congestion Notification (ECN) 6] has opened new avenues. Without dropping packets and thus causing a later retransmit or even a time out, it is now possible to indicate congestion to participating transmission protocols by setting a mark in the packet ....

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. In Proceedings of 7th International Workshop on Quality of Service (IWQoS '99), London, pages 260--262, June 1999.

....Second, congestion control remains a hard and open problem. As a community, we have made many advances since the installation of congestion control in the Internet in 1989 [39] However, there are still many open problems such as the need for a less oscillatory and more predictable behavior [54] and better fairness over shorter time scales [12] Thus, this dissertation proposes a new architecture for managing Internet bandwidth that is based on decoupling congestion control from the bandwidth allocation policy. It shows that this approach stays efficient as the per flow bandwidth delay ....

....queue is smaller than the departure rate. Consequently, any persistent real queue is bound to drain after some time. There is a large amount of research that attempts to characterize the various AQMs. Yet, the community still has concerns about the safety of deploying AQM schemes in the Internet [54]. 23 One important problem with AQM schemes is the existence of many tunable parameters whose values significantly affect the performance. Good operational values for these parameters depend on the number of flows traversing the bottleneck, the capacity of the bottleneck, and the round trip ....

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy red, June 1999.

.... of TCP [1, 2] One of promising gateway based congestion control mechanisms is a RED (Random Early Detection) gateway that randomly drops an incoming packet at the bu er [1] A number of studies on the steady state performance of the RED gateway using simulation experiments have been performed [1, 3, 4]. Although e ectiveness of the RED gateway is fully dependent on a choice of control parameters, it is dicult to con gure them appropriately. For example, the authors of [1] have proposed a set of control parameters for the RED gateway, but this is only a guideline acquired empirically using ....

M. May, J. Bolot, C. Diot, and B. Lyles, \Reasons not to deploy RED," in Proceedings of IWQoS '99, pp. 260-262, Mar. 1999.

....Standard Deviation [packets] ECN 19.8 4.2 Proposed Rate Control 23.3 5.5 # ##### should be set higher than #### . However, in this paper, since we focus on achieving the fairness rather than stabilizing the queue length, and parameter setting of RED is important and difficult issue[12], we may leave this problem as a further research. VI. Conclusions In this paper, we proposed a TCP rate control using ECN mechanism for achieving the fairness among TCP connections at a bottleneck link. In the proposed rate control, the modified ECN mechanism is employed and the bottleneck ....

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons not to Deploy RED," The 7th International Workshop on Quality of Service(IWQoS'99), pp. 260-262, June. 1999.

....These parameters should be tuned considering the network and traffic architecture. The effectiveness of the RED algorithm on congestion control and reduction of the loss rate is proven by both simulations and real world experiences [6, 11] However, the algorithm has parameter selection problems [12, 13]. In order to benefit from the algorithm its parameters must be arranged properly. Moreover, the marking aggressiveness of the algorithm is insensitive to the number of active flows on the gateway. When the bottleneck link is shared equally between the active flows, marking one packet to send ....

May. M., Bolot, J., Diot, C., Lyles, B., 1999, Reasons not to deploy RED, INRIA Sophia-Antipolis, ENSIM, Sprintlabs

....high delays [1] Past research efforts focused on configuring AQM systems such as RED [2] and numerous variants thereof [3] 7] for service level specifications. In particular, the difficulty in finding the appropriate parameters for RED for any combination of offered load was pointed out in [8], 9] In general, AQM schemes are not able to achieve accurate bandwidth guarantees. Depending on the underlying hardware, a full featured scheduler might not be available (e.g. there is only a priority scheduler, a WRR scheduler, or a FIFO queue) and therefore absolute bandwidth guarantees ....

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. In Proc. of 7th Int. Workshop on Quality of Service (IWQoS '99), London, pages 260--262, June 1999.

....settings of max p and max thresh [76] The recommended values for the various RED parameters are shown in Table 2. However, these settings have been shown to give poor performance in many situations. In fact, RED is notoriously hard to con gure to improve over the performance of drop tail queues [46, 125]. The EWMA lter has for purpose to take into account the history of queue occupancy as opposed to the instantaneous queue size. This allows occasional short bursts to be admitted, while ensuring that the average queue size is small. The random drop function is designed to distribute the loss ....

....usage. In addition, experimental work has shown that RED does not perform better than Tail drop. For a large number of connections, the router queue length was found to stabilize around the max thresh , which means that a RED queue behaves like a Tail drop queue with a size equal to that threshold [62, 63, 125]. Conversely, when the number of connections is small, the drop function of RED becomes overly aggressive and results in under utilization of the link. A self con guring Adaptive RED gateway (ARED) was proposed to address these limitations. ARED dynamically modi es max p as the average queue size ....

May M., Diot C., Lyles B., Reasons not to Deploy RED, in Proceedings of the IEEE/IFIP IWQoS, June 1999.

....However, some studies show that the chosen configuration parameters (th min , th max , Pmax ) have a crucial influence on the behavior of RED and its impact on the tra#c that is traveling through the node. Inaccurate values for these parameters can lead to undesired performance of the mechanism [4, 9]. In order to make the behavior of RED more resistant to strong changes of the tra#c condition and limit the impact of poor configurations, two variants of the RED algorithm have been developed: Gentle RED: If the configured thresholds for RED are chosen too low, this leads to very frequent ....

.... of poor configurations, two variants of the RED algorithm have been developed: Gentle RED: If the configured thresholds for RED are chosen too low, this leads to very frequent and numerous packet drops, which is quite similar to the behavior and impact of the standard tail drop principle [9]. Also, in situations where the tra#c condition changes too often, the behavior of RED can be too restrictive. Therefore, a modified RED version was proposed in [4] that in all shows a more friendly behavior and is called Gentle RED. In this variation, not all packets are discarded, as soon as ....

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. In Proceedings of the 7th IFIP Workshop on Quality of Service, London, Piscataway, NJ, USA, June 1999. IEEE.

....algorithm overcomes the configuration problem with Random Early Detection (RED) which is in variations used as active queue management algorithm in most AF implementations. The difficulty with RED is to determine the correct drop precedence parameters for any combination of offered loads [5] [7] RED parameters are specified as thresholds for the average queue occupancy (which can also be regarded as delay thresholds) rather than in packet rates as would be convenient for configuration. If discard rates during long term congestion cannot be correctly configured, service level ....

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons Not to Deploy RED," in Proceedings of the Workshop on Quality of Service (IWQoS'99), June 1999, pp. 260--264.

....resulting transient congestion. Since RED [2] was proposed in 1993, many AQM based approaches such as BLUE [3] Adaptive RED [4] REM [5] PI Controller [6] etc. have been proposed. However, many AQM proposals have shown severe problem with the (average) queue length as a congestion indicator [7, 6, 8, 9]. One important drawback of currently proposed AQM algorithms is that their congestion detection and control functions depends only on the current queue status or history of queue length status (e.g. average queue length) Hence the congestion detection and control in these algorithms play ....

May, M., J. Bolot, C. Diot, and B. Lyles, "Reasons not to deploy RED," Proceedings of IEEE/IFIP IWQoS'99, June 1999.

....marking is in effect. This permits ECN to display its best potential with respect to the ECN capable flows present. However, it is known that tuning RED parameters so that routers in real networks, experiencing a variety of traffic mixes, are always operating in the RED region is difficult [5][9]. This paper presents case studies using simulation in which there is no background traffic. Traffic in our studies is ECN capable, and is not constructed to ensure any particular, a priori relationship with respect to the RED parameters in effect. We also focus on moderately short (100 KB) ....

May, M., Bolot, J., Diot, C., and Lyles, B.: Reasons Not to Deploy RED. In: Proc. of 7 th International Workshop on Quality of Service (IWQoS'99), London, UK, June 1999.

....be identified in the next section. Most of the rules for setting these parameters are empirical, and come from networking experience. These rules have been evolving as the effects of controller parameters are not very clearly understood. There are papers discouraging implementation of RED (e.g. [9]) arguing that there is insufficient consensus on how to select controller parameter values, and that RED does not provide a drastic improvement in performance. Initially, there was very little in the way of mathematical modeling of TCP RED. However, with the recent efforts toward modeling TCP ....

M. May, J. Bolot, C. Diot, B. Lyles , "Reasons Not to Deploy RED," Proc. IWQoS'97, 1997.

....and (4) the constant value used by the exponential filter to average the queue length. A delicate issue with RED is that it requires fine tuning of many parameters in order to work properly. Consequently, there is considerable nervousness in the community regarding the deployment of RED [10] 20] [21], 22] Several complex variants of RED have been proposed in order to obtain algorithms less sensitive to parameter tuning. In [29] stabilized RED (SRED) is proposed, which aims at stabilizing buffer occupation by estimating the number of active connections in order to set the drop probability as ....

May, M., Bolot, J., Diot, C., Lyles, B.: Reasons not to deploy RED. Seventh International Workshop on Quality of Service IWQoS (1999)

.... to configure for some rapidly changing traffic mixes and loads [2] Other studies show that under some conditions, the performance gains of RED and its variants over traditional drop tail queue management is not significant given the additional complexity required for proper configuration [9, 3]. Recent variants of RED, such as Adaptive RED [8] are designed to provide more robust RED performance under a wider range of traffic conditions. This paper provides additional analysis of RED and newer variants of RED over a wider range of traffic mixes and loads than has previously been ....

....does not significantly oscillate and stays under max th . Other researchers conclude that RED is too complicated to configure, and show that end to end performance of RED is no better than drop tail queue management, and may even be worse than that of drop tail queue management in some cases [2, 3, 9]. While RED does ensure a tightly bounded upper limit on the average queue length, it can result in many consecutive packet drops [3] that can significantly decrease end to end throughput and goodput by causing TCP timeouts. These reports raise the concern that using RED router queue management is ....

[Article contains additional citation context not shown here]

Martin May, Jean Bolot, Christophe Diot, and Bryan Lyles. Reasons not to deploy RED. In Proceedings of the IEEE/IFIP International Workshop on Quality of Service (IWQoS'99), June 1999. 9

.... to configure for some rapidly changing traffic mixes and loads [2] Other studies show that under some conditions, the performance gains of RED and its variants over traditional drop tail queue management is not significant given the additional complexity required for proper configuration [9, 3]. Recent variants of RED, such as Adaptive RED [8] are designed to provide more robust RED performance under a wider range of traffic conditions. This paper provides additional analysis of RED and newer variants of RED over a wider range of traffic mixes and loads than has previously been ....

....does not significantly oscillate and stays under . Other researchers conclude that RED is too complicated to configure, and show that end to end performance of RED is no better than drop tail queue management, and may even be worse than that of drop tail queue management in some cases [2, 3, 9]. While RED does ensure a tightly bounded upper limit on the average queue length, it can result in many consecutive packet drops [3] that can significantly decrease end to end throughput and goodput by causing TCP timeouts. These reports raise the concern that using RED router queue management is ....

[Article contains additional citation context not shown here]

Martin May, Jean Bolot, Christophe Diot, and Bryan Lyles. Reasons not to deploy RED. In Proceedings of the IEEE/IFIP International Workshop on Quality of Service (IWQoS'99), June 1999. 9

.... our TCP friendly marking component can achieve baseline gains even without this extension (see section 6) Also since FRIO and RIO are fundamentally variants of the basic RED algorithm, they inherit some of its parameter sensitivity issues, which may degrade performance under certain conditions [17]. However, we shall see later in this paper that the determinism in the marking process effectively masks such parameter sensitivities. 6 Performance Analysis and Experimentation Router Router Router . 100 Mbps 100 Mbps 10 Mbps 100 Mbps Traffic Conditioning Differential ....

....in our experiments to capture: a) the two most important and commonly deployed TCP implementations (Reno and SACK) as well as, b) good or mistuned setting of RED equivalent parameters. We consider good RED parameters as those in which the max and min thresholds are relatively far apart [17]. Mistuned parameters are those where the thresholds are set too close to each other, which in effect defaults to a taildrop policy on a smaller buffer limit. Parameter mistuning risk is one of the leading reasons why RED is not widely deployed today and our marking scheme can help mitigate this ....

[Article contains additional citation context not shown here]

M. May et al, "Reasons not to deploy RED," IWQoS'99, June 1999.

.... have shown that RED can lead to worse TCP performance under a variety of scenarios, but in particular for small transfers [5] Although the current Internet Engineering Task Force (IETF) recommendation is for the deployment of RED [4] network operators seem to be reluctant to proceed with it [6]. In a recent study [7] we have investigated the impact of ECN on TCP performance for large transfers with many clients. In this paper, we focus on the case of two flows, which highlights some exceptional characteristics that do not manifest themselves in the case of many clients. 2 Simulation ....

M. May, J. Bolot, C. Diot, and B. Lyles, Reasons Not to Deploy RED, Proc. 7th Int. Workshop on Quality of Service (IWQoS'99), London, UK, June 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons not to deploy RED," in Proc. Int. Workshop Quality-of-Service (IWQoS), 1999, pp. 260--262.

No context found.

Martin May, Jean Bolot, Christophe Diot, and Bryan Lyles. Reasons not to deploy RED. In Proceedings of 7th International Workshop on Quality of Service (IWQoS), London, pages 260--262, June 1999.

....load) Measurement results for FTP like traffic are discussed in section 4 and simulation results for more realistic Web like traffic are analyzed in section 5. Finally, section 6 concludes this paper and summarizes the findings. 2. Related Work As an important starting point for this paper, [19, 12] compare TD, RED and GRED employing standard parameter settings. The main conclusions of these papers are that RED does not improve performance compared to TD, and that tuning of RED parameters is still an open question but should not have a big influence on performance. Similarily, 4] shows that ....

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. In Proc. of 7th. International Workshop on Quality of Service (IWQoS'99), London, pages 260--262, June 1999.

....FTP ows to illustrate the performance of the algorithms in the simpler steady state case, while section 6 employs realistic Web tra c for performance evaluation. Finally, section 7 concludes this paper and summarizes the ndings. 2 Related Work As an important starting point for this paper, [11][12] compare TD, RED and GRED employing standard parameter settings. The main conclusions of these papers are that RED does not improve performance compared to TD, and that tuning of RED parameters is still an open question but should not have a big in uence on performance. Similarily, 13] shows ....

M. May, J. Bolot, C. Diot, B. Lyles, "Reasons not to deploy RED", Proceedings of IWQoS 1999

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. In Proc. of 7th Int. Workshop on Quality of Service (IWQoS '99), London, pages 260--262, June 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons not to deploy RED," in Proceedings of IWQoS '99, pp. 260--262, Mar. 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons Not to Deploy RED," Proceedings of IWQoS'99, London, Mar. 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons Not to Deploy RED," IEEE/IFIP IWQoS, June 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons not to deploy RED," Proc. of the IEEE/IFIP International Workshop on Quality of Service (IWQoS'99), June 1999

No context found.

May, M., Bolot, J., Diot, C. and B. Lyles, "Reasons not to deploy RED", Proc. of 7th. International Workshop on Quality of Service (IWQoS'99), June 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. In to be presented at IWQoS'99, London, June 1999. preprint available from http://199.2.52.7/PEOPLE/diot/.

No context found.

Martin May, Jean Bolot, Christophe Diot, and Bryan Lyles, "Reasons not to deploy RED," in Proceedings of IWQoS'99, June 1999.

No context found.

May. M., Bolot, J., Diot, C., Lyles, B., 1999, Reasons not to deploy RED, INRIA Sophia-Antipolis, ENSIM, Sprintlabs, http://www-sop.inria.fr/rodeo/personnel/mmay/may-red.html

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons Not to Deploy RED. Proc. of 7th. International Work-shop on Quality of Service (IWQoS'99), pages 260--262, June 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. In Proceedings of 7th International Workshop on Quality of Service (IWQoS '99), London, pages 260--262, June 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons Not to Deploy RED," IEEE/IFIP IWQoS, June 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons not to deploy RED," in Proceedings of IWQoS '99, pp. 260--262, Mar. 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons not to deploy RED," in Proc. IWQoS'99, June 1999, pp. 260--262.

No context found.

Martin May, Jean Bolot, Christophe Diot, and Bryan Lyles, "Reasons not to deploy RED," in Proceedings of IWQoS'99, June 1999.

No context found.

Martin May, Jean Bolot, Christophe Diot, and Bryan Lyles, "Reasons not to deploy RED," in Proceedings of IWQoS'99, June 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons not to deploy RED," in Proceedings of IWQoS '99, pp. 260--262, Mar. 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. In Proc. of 7th Int. Workshop on Quality of Service (IWQoS '99), London, pages 260--262, June 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons not to deploy RED," in Proceedings of IWQoS '99, pp. 260--262, March 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. In Proc. of 7th Int. Workshop on Quality of Service (IWQoS '99), London, pages 260--262, June 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to deploy RED. Technical report, INRIA Sophia-Antipolis, France, 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles. Reasons Not to Deploy RED. Proc. of 7th. International Work-shop on Quality of Service (IWQoS'99), pages 260-262, June 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons not to deploy RED," in Proceedings of IWQoS '99, pp. 260--262, Mar. 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons not to deploy RED," in Proceedings of IWQoS '99, pp. 260--262, Mar. 1999.

No context found.

M. May, J. Bolot, C. Diot, and B. Lyles, "Reasons not to deploy RED," in Proceedings of IWQoS '99, pp. 260--262, Mar. 1999.

No context found.

M. May, J. Bolot, C. Diot, B. Lyles, "Reasons not to deploy RED," Seventh International Workshop on Quality of Service, IWQoS'99, London, England, June 1999.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC