Martin.may.free.fr

Comparison of Tail Drop and Active Queue Management Performance for
bulk-data and Web-like Internet Traffic
Abstract
a congested router output port. Traditional Internet routersemploy “Tail Drop” (TD) queue management, discarding This paper compares the performance of Tail Drop and arriving packets if the buffer of the output port overflows.
three different flavors of the RED (Random Early Detection) Contrary to TD, active queue management (AQM) mech- queue management mechanism: RED with a standard pa- anisms [10] start dropping packets earlier to enable notifi- rameter setting, RED with an optimized parameter setting cation of traffic sources about the incipient stages of con- based on a model of RED with TCP flows, and finally a ver- gestion. Recently, AQM mechanisms [5, 2] have been pro- sion of RED with a smoother drop function called “gentle posed within the framework of the Internet differentiated RED”. Performance is evaluated under various load situa- services architecture [1] to preferentially drop non conform- tions for FTP-like and Web-like flows, respectively. We use measurements and simulations to evaluate the performance The Random Early Detection (RED) AQM algorithm of the queue management mechanisms and assess their im- [10, 2] has been designed to substitute TD and is nowadays pact on a set of operator oriented performance metrics. We widely implemented in commercially available routers.
find that in total (i) no performance improvements of RED RED uses the parameter set minth , maxth , maxp , wq compared to Tail Drop can be observed; (ii) fine tuning order to probabilistically drop packets arriving at a router of RED parameters is not sufficient to cope with undesired output port. RED maintains an average queue size (avg ) RED behavior due to the variability in traffic load; (iii) gen- which is computed as an exponentially weighted moving tle RED is capable of resolving some of the headaches on average of the instantaneous queue size with weight pa- rameter wq . If the avg is smaller than minth , no packet Keywords: TCP, RED, performance evaluation
probability varies linearly between zero and maxp .
maxth , the drop probability equals one. Gentle RED 1. Introduction
(GRED) [9] modifies RED’s dropping function for the casethat avg exceeds maxth , as illustrated in fig. 1. The drop Internet best effort traffic is controlled through the inter- probability increases linearly between maxth and the buffer action of end-to-end congestion control and queue manage- ment. TCP’s end-to-end congestion control [13, 14] adapts well as GRED have to drop an arriving packet if the instan- the volume of transmitted data to the current load situation taneous queue size equals the total buffer size.
in the net by varying the congestion window as a function It has been claimed in [10] that RED yields advantages of the packet loss rate. Queue management is the decision compared to TD mainly in terms of accomodation of bursts when to start dropping packets and which packets to drop at and avoidance of global synchronization, i.e. TD’s tendency 1The authors are funded by the IST project Aquila and a research grant of synchronizing TCP flows to be in phase by dropping packets of several flows at one instance in time. Global syn- termining the equilibrium point (i.e. the queue average over infinite time intervals), the required difference between thequeue size thresholds maxth and minth to keep the amplitude of the oscillation around the equilibrium point sufficiently Figure 1. RED and GRED
Finally, [27] shows that, independently of the parame- ter settings, RED-like mechanisms tend to oscillate in thepresence of two-way TCP traffic in scenarios lacking heavy chronization has the potential to make the queue size oscil- late, causing suboptimal throughput and high delay jitter. Inorder to avoid global synchronization, it has been a design 3. Evaluation Environment
goal of RED to spread out packet losses in time, in otherwords to minimize the number of consecutive packet drops.
It is common knowledge, however, that global synchroniza- 3.1. Performance Metrics
tion is only a problem in lightly loaded scenarios and in-finite length TCP flows [24, 18]. Additionally, suboptimal We are interested in the aggregate traffic performance of throughput due to global synchronization can be avoided as queue management mechanisms and not in individual flow long as the buffer size is set to the bandwidth*RTT product performance or fairness issues. We argue that it makes sense to look at the aggregate traffic behavior first, because earlier In this paper we evaluate potential benefits of various papers have already investigated the individual flow perfor- RED flavors over TD which might give ISPs an incentive to mance as well as fairness [20, 16, 4] and second, because migrate from TD to RED. The rest of this paper is organized ISPs are interested in optimizing aggregate traffic perfor- as follows: section 2 summarizes related work; section 3 mance. In this paper a traffic mix consisting of TCP flows has all the details of the evaluation environment (metrics, and constant bit rate UDP flows is used. The total UDP ar- testbed and simulation setup, traffic load). Measurement rival rate equals 10% of the bottleneck link capacity. Simi- results for FTP-like traffic are discussed in section 4 and lar to [12], the performance metrics are: simulation results for more realistic Web-like traffic are an- TCP goodput is defined as the number of bits per second
alyzed in section 5. Finally, section 6 concludes this paper forwarded to the correct destination interface, minus any bits lost or retransmitted. We decided not to study TCP lossbecause loss and goodput are somewhat redundant metricsfor TCP (TCP adapts its congestion window as a function 2. Related Work
of the loss rate) and because for TCP flows goodput is ofmajor interest.
As an important starting point for this paper, [19, 12] UDP loss rate is defined as the number UDP packets that
compare TD, RED and GRED employing standard param- are dropped divided by the total number of UDP packets eter settings. The main conclusions of these papers are that that arrived at the same output port. For UDP flows the loss RED does not improve performance compared to TD, and rate is an equivalent metric to the goodput for TCP flows.
that tuning of RED parameters is still an open question but This is an incentive to study aggregate UDP loss which is should not have a big influence on performance. Similar- strongly correlated to the loss rate of individual flows.
ily, [4] shows that RED exhibits no clear advantages over Queueing delay: minimizing queueing delay is of in-
TD concerning response times of Web transfers and that the terest for transaction-like applications, e.g. remote login or setting of RED parameters influences response time perfor- Web transfers. For the testbed measurements the queue- ing delay is measured inside the dummynet tool as the dif- Several publications discussing the setting of RED pa- ference between the time the scheduler starts servicing a rameters give either rules of thumb and qualitative recom- packet and the time this packet is enqueued in the output mendations [15, 8, 25] or quantitative models assuming in- buffer. In order to increase the precision of the measure- finite time averages [7] which are not capable of modelling ments, the kernel clock rate in the machine running dum- the oscillatory behavior of the RED queue. A control the- mynet is set to 1000 HZ, resulting in a 1 ms granularity for oretic approach to model the parameter setting of RED is Standard deviation of queueing delay: queue variance
In [26] a quantitative model how to set RED parameters corresponds directly to delay jitter of flows. We decided with TCP traffic is derived. The RED parameters relevant to measure the standard deviation of the queueing delay in- for stability are the maximum drop probability (maxp ) de- stead of the delay jitter of individual flows (i.e. the standard deviation in a flow’s interarrival time of packets at the re- occur, is emulated using dummynet [23], a link emulator ceiver) because delay jitter is not capable of reflecting low that runs on a FreeBSD machine acting as a bridge between frequency oscillations in queueing delay in many scenarios.
the two routers. Dummynet also executes the queue man- Consecutive loss distribution: the mean of the con-
agement mechanisms under investigation.
secutive loss distribution is an important quality criterion In all experiments the bottleneck link has a capacity of for queue management mechanisms as it indicates suscep- 10 Mbps and a 100 ms propagation delay. The links from tibility to global synchronization. We define the random PCs 1–4 to router1 have a propagation delay of 20, 40, 60, variable N as the number of consecutive losses observed at and 80 ms, respectively. All other links have a negligible a router output port and consider the probability distribu- propagation delay, so that the end-to-end round trip propa- n . In the measurements, the dummynet tool gation delay ranges approximately from 120–180 ms.
measures the loss events which begin when a first packet is The MTU size equals 573 bytes for UDP packets and dropped and end when the first arriving packet is accepted 1514 bytes for TCP packets. Linux implements TCP SACK [17]. Each measurement lasts for 500 seconds, where the The different mechanisms compared in this paper are initial 100 seconds are not considered in order to filter out TD, RED and GRED with a standard parameter setting the startup behavior of the system; all measurements are re- (REDstd, GREDstd), and RED with an optimal parame- peated 10 times and figures are plotted with 95% confidence ter setting (REDopt). REDstd and GREDstd means that minth , maxth , and the buffer size are set reasonably high(i.e. in the range of the bandwidth*RTT product of the sce- 3.3. Simulation Environment
nario); maxp is set to 0.1 and wq is set to 0.002, as recom-mended in [8]. We define a configuration of RED param- For simulations with the ns-2 simulator [21] we use a eters as optimal (REDopt) if it makes the queue size con- topology (fig. 2(b)) similar to the measurement setup. Traf- verge to (minth +maxth )/2 with only small amplitude oscil- fic is multiplexed on the 100 Mbps links between router0 lations in case of infinite-demand FTP-like flows. Such a and router1, respectively router3 and router2, before it ar- queue size behavior is achieved by setting RED parame- rives at the bottleneck link. Output ports transmitting on ters according to the model proposed in [26] and summa- the 100 Mbps links use TD queue management. Packet rized in section 2. This model is, however, designed for drops happen solely at the 10 Mbps link between router1 RED with TCP flows only and not for a mix of TCP plus and router2 where persistent congestion occurs. The queue 10% non-responsive UDP traffic. For this reason we have management algorithm under investigation is executed at applied some minor adaptations to the model. The bottle- the output port of router1. Data senders are located at hosts neck link capacity B used as an input to the model is com- 1–4. Delays of access links are configured such that the av- Plossud p , where Rud p denotes the erage end-to-end propagation delay equals the end-to-end total arrival rate of UDP flows and Plossud p denotes an es- delay for the measurements. TCP packet sizes are evenly timator for the loss probability of UDP flows. Thus B de- distributed from 1400 to 1628 bytes with a mean of 1514 notes the fraction of the bottleneck capacity available to the bytes. UDP packet sizes are set to 573 bytes.
TCP flows. Additionally, as a mix of TCP flows and 10% Flows start during the first 10 seconds of simulation time.
unresponsive UDP traffic behaves more aggressively than Simulations last for 5000 seconds; the initial 100 seconds TCP only, we multiply the maxp parameter computed by the are not considered. With respect to the heavy tailed distri- model by a factor 1.1 in order to adapt RED’s aggressive- butions, all simulations are run 50 times (1000 simulations in total) to get tight 95% confidence intervals as shown inthe figures.
3.2. Measurement Environment
3.4. Network Traffic
The testbed network (fig. 2(a)) used for experiments is meant to represent a gateway where many networks are In each measured and simulated scenario, the back- merged into one outgoing link. All hosts are Pentium PCs ground traffic is comprised by four constant bit rate UDP running Linux. The PCs have two network cards to enable sources that transmit with an aggregate rate of 1 Mbps (i.e.
different paths for incoming and outgoing traffic; this pre- 10% of the bottleneck bandwidth) from hosts 1–4 to hosts cludes collisions at the link layer. Moreover, PCs 1–4 run a 5–8. The foreground traffic is comprised by an aggregate dedicated application to insert additional propagation delay of either FTP-like or Web-like TCP sources as described in on outgoing traffic to router1. The two routers are Cisco FTP-like TCP flows: In order to investigate the steady The bottleneck link, where congestion and packet drops state behavior of the different queue management algo- 100 Mbps half duplex Ethernet, direction left to right 10 Mbps half duplex Ethernet, direction left to right 10 Mbps half duplex Ethernet, direction right to left Figure 2. Topology of testbed and simulated network
rithms, we analyze traffic from everlasting FTP-like TCP 4. Measurements with bulk-data traffic
SACK flows. In each set of measurements and simulationsthe load is varied over a broad range by varying the number In order to keep queue oscillation at a constant ampli- of TCP flows. Within the context of window-based con- tude, the model [26] used to calculate the parameters for gestion controlled flows like TCP, we define the load as the REDopt results in a setting of minth , maxth and buffer size number of flows divided by the bandwidth*RTT product.
(in packets) dependent on the number of flows. Thus, in Investigations with FTP-like TCP traffic are performed order to allow for comparison of the queue management by measurements and simulations. However, the simulation mechanisms, the buffer sizes for (G)REDstd and TD are results are not shown in the paper due to space limitations.
set to the same values as for REDopt. The bandwidth*RTTproduct of the scenario equals approximately 300 packets Web-like TCP flows: In order to investigate the behavior (including queueing delay), which is close to the buffer size of the queue management algorithms with more realistic In- ternet traffic we employ a model for Web traffic developed The minth parameter for (G)REDstd is set to 3/20 times in [6]. It is a model of HTTP 1.0 traffic which provides sev- buffer size and the maxth parameter for (G)REDstd is set to eral distributions that describe user behavior and properties 13/20 times buffer size. The load is varied by changing the of Web pages. Please see [6] for the details of the model.
number of TCP flows from 16 to 256. The detailed param- The choice of parameters is based on [6] and summarized eter settings are shown in fig. 3(a).
[TCP goodput] The TCP goodput results are practically
Our simulations rely on an implementation of the de- equal for all queue management mechanisms. In all scenar- scribed traffic model that is being shipped with recent dis- ios goodput is almost optimal (around 8.4 Mbps) as queues hardly ever drain completely and TCP SACK avoids un- We adapt the load by varying the number of Web ses- necessary retransmissions. In conformance with earlier re- sions. The average number of TCP flows required for the sults, global synchronization does not cause a goodput de- REDopt parameter model [26] is estimated through the av- crease with TD in lightly loaded scenarios. The goodput erage number of active flows observed over the entire sim- is marginally below optimal with GRED and REDstd for ulation. Note that investigations with Web traffic are per- the 16 flows scenario as a maxp of 0 1 causes (G)REDstd to drop packets too aggressively for the given flow aggregate.
This causes the equilibrium point of the (G)REDstd queuesize to stay close to minth which increases the likelihood for [UDP loss] Fig. 3(b) illustrates that REDopt is better
than REDstd and GREDstd by a factor 2 in lightly loaded scenarios concerning the relative difference in UDP loss.
TD is in between. In heavily loaded scenarios, the relative Table 1. Distributions for Web traffic model
differences decrease and are too small to be considered rel-evant.
(d) Consecutive loss distribution (256 flows) Figure 3. Measurements with FTP traffic
[Queueing delay] As the buffer size, maxth , and
nization, causing a high standard deviation of the queueing minth parameters are increased directly proportional to the delay (see fig. 3(e)). As the load increases, the global syn- number of flows, queueing delay increases likewise for all chronization effect disappears; the TD queue stays close to mechanisms (see fig. 3(c)). With TD the queue converges the total buffer size and thus the delay variation decreases to the total buffer size, while the average queue size stays below maxth with RED – thus queueing delay is signifi- [Consecutive losses] For lightly to medium loaded sce-
cantly smaller with RED. Note, however, that this can notbe considered as an argument against TD. The selection of narios (i.e. less than 64 flows in our case) all RED mech-anisms show equal performance concerning the number of the buffer size always means balancing a tradeoff between consecutive losses. As the average queue size stays below high queueing delay and low link utilization. We have exe-cuted simulations showing that TCP goodput, with the TD maxth , RED is able to buffer traffic bursts without perform-ing consecutive forced drops. TD is significantly worse than buffer size set so that TD queueing delay equals the REDopt the RED variants as the queue size is frequently very close queueing delay, is the same for TD and REDopt.
to the total buffer size, enforcing consecutive packet drops Comparing (G)REDstd and REDopt we find that the in case a burst of packets arrives and causing global syn- average queueing delay varies significantly less with RE- Dopt as a function of the number of TCP flows. This isdue to the fact that REDopt adapts the max performs badly as the average queue size often execeeds the load, so that the average queue size always stays closeto (min maxth , enforcing frequent consecutive packet drops (see fig. 3(d)). Due to GREDstd’s smoother drop function con- maxp constant, causing a drift of the average queue from secutive drops are less likely with GREDstd than with RED- minth to maxth as the number of flows increases (see [26]).
std. REDopt keeps the average queue size below maxth and [Delay variation] In case of lightly loaded scenarios the
thus avoids consecutive drops in general. However, from queue size oscillates heavily with TD due to global synchro- time to time a traffic burst causes the average queue to ap- Standard deviation of queueing delay (ms) (d) Consec. loss distribution (1400 sessions) Figure 4. Simulations with Web traffic
proach maxth , causing a heavy tail in the REDopt consecu- while maxp increases by a factor 16.7 if the number of ses- sions increases from 1200 to 1400. This shows the highlynon-linear behavior of the network load as a function of the 5. Simulations with Web-like Flows
number of Web sessions and that the spectrum of load sit-uations where AQM is able to control the system dynamicsis very limited.
While the study of FTP-like traffic was done both with measurements and simulations (showing very good confor- [TCP goodput] TCP goodput increases monotonically
mance) the study of Web-like flows is restricted merely to with the number of Web sessions (i.e. the load) and con- simulations. The adaptation of buffer sizes for (G)REDstd verges to a maximum of 8.7 Mbps for the high load sce- and TD is done in the same way as described in the first two narios. The monotonic increase is due to the decreasing paragraphs of section 4. The detailed parameter settings are probability that the queue is empty because of underload.
No significant differences between the queue management The load is varied by changing the number of Web ses- sions from 800 to 1400. Scenarios with fewer sessions than [UDP loss] Fig. 4(b) illustrates the non-linearity in sys-
800 were underloaded and thus not of interest. On the other tem load as a function of the number of Web sessions. The hand, simulations with more than 1400 sessions led to a sit- increase of the UDP loss rate curves (indicating network uation where the network was extremely overloaded. The load) over the number of sessions is significantly non-linear flow lifetime became thus very long and the situation con- and completely contrary to the loss rate curves for FTP traf- verged to the scenarios with FTP-like traffic. A good indica- fic (see fig. 3(b)). TD generally has a lower loss rate, espe- tor for the network load is REDopt’s maxp parameter which cially for 1200 Web sessions; the other scenarios show only equals 2 times the estimated drop probability of a scenario [26]. As can be seen in fig. 4(a), maxp increases by a factor2.6 if the number of sessions increases from 800 to 1000, [Queueing delay] As shown in fig. 4(c), the infinite-time
average of the queueing delay increases proportionally with cess (low value for wq ) is taken into account.
the number of Web sessions for all mechanisms because thequeue size thresholds determined by the model for REDopt 6. Conclusions
increase likewise. As REDopt adapts maxp to the networkload, it is best in making the infinite-time average of the We have compared the performance of Tail Drop (TD), queue size converge close to (minth +maxth )/2, causing the RED and GRED with a standard parameter setting (RED- average queueing delay to increase only moderately as a std, GREDstd) and RED with fine-tuned parameter setting function of the number of Web sessions. All other mechan- (REDopt). Performance metrics are TCP goodput, UDP sisms are not able to control the infinite-time average of the loss rate, average queueing delay, standard deviation of the queue size, causing the steep increase of the queueing de- queuing delay (as an indicator for delay jitter) and the con- lay. For TD, the average queueing delay is generally higher secutive loss probability distribution. The analysis is per- than for RED because TD’s average queue has the tendency formed with a traffic mix consisting of FTP-like TCP flows to converge to the buffer size while for RED it does not ex- and 10% of UDP traffic, as well as a traffic mix consist- ing of Web-like TCP flows and 10% UDP traffic for various [Delay variation] In case of Web traffic the standard de-
viation of the queueing delay is mainly determined by the burstiness of the arriving traffic in medium load scenarios.
The performance differences are partly due to the different the mechanisms do not show significant differences ranges of queue size variation allowed by the mechanisms.
concerning TCP goodput and UDP loss.
For instance, TD allows variation between zero and the en- In all load situations for FTP and Web traffic, REDopt tire buffer size while REDstd allows variation between zero is superior in controlling the average queueing delay.
and maxth , thus REDstd generally has a smaller standarddeviation of queueing delay than TD. Similar to scenarios TD exhibits higher variation in the standard deviation with FTP traffic the standard deviation of TD decreases if of the queueing delay as a function of the load than the load increases because the queue size exhibits a ten- the RED variants. Moreover, we observe that longer dency towards convergence to the total buffer size.
memory in RED’s computation of the average queue Comparing (G)REDstd and REDopt we observe that size increases the standard deviation of queueing delay REDopt has a higher standard deviation, independently of the settings of maxp (for low load scenarios REDopt has asmaller max p than REDstd, vice versa for high load scenar- GREDstd and REDopt are significantly better than ios). The settings for minth and maxth are approximately the REDstd concerning consecutive losses for medium same. Thus, as the queue weight is the only remaining pa- to high load scenarios in case of FTP traffic.
rameter, the longer memory in REDopt’s queue size aver- In these scenarios the RED queues stay close to aging (REDopt has a smaller queue weight than REDstd) the maxth threshold, frequently causing consecutive seems to have a negative effect on the standard deviation of the queueing delay with Web traffic.
AQM mechanisms fail to keep the average queue sizeaway from maxth due to the high variability in traffic [Consecutive Losses] Fig. 4(d) shows that the RED vari-
load. Consequently, these mechanisms perform badly ants are significantly worse than TD concerning consecutive in terms of consecutive losses. On the other side, TD drops. While REDopt is able to keep the queue size below performs well concerning consecutive losses, quite in- maxth for FTP traffic (see section 4) and thus avoids con- dependently of the load situation for FTP and Web traf- secutive losses, it fails to do so for the Web traffic. Due to fic. Note that these kinds of forced consecutive packet the high variability and burstiness of Web traffic the aver- drops with RED cause mechanisms like ECN [22] to age queue size (of all RED variants) frequently approaches maxth , causing consecutive losses.
We looked at different load situations and took into ac- Basically, the performance of REDstd is sensitive to the count the different settings of maxp and wq of the mecha- load situation for most of the used metrics, which can be nisms under investigation. From these observations it be- considered as a serious drawback. REDopt is less sensitive comes obvious that a higher value for wq (i.e. shorter mem- to the load situation as its parameters are adapted based on ory in the queue averaging) decreases the probability for a model assuming knowledge of the network scenario (bot- long periods of consecutive drops. This is due to the fact tleneck bandwidth and RTT) and the load situation. How- that once the average queue size is close to maxth , it will ever, in realistic scenarios with Web traffic the load situa- stay there longer the more history from the averaging pro- tion (e.g. number of TCP flows and their demand) varies heavily, thus REDopt is not capable of resolving the draw- Infocom, Tel Avivthe 2000 IEEE Computer and Communi- backs inherent to RED. However, models as proposed in cations Societies Conference on Computer Communications [7, 11, 26] provide important insights on how to set the pa- (INFOCOM-00), pages 1435–1444, Mar. 2000.
rameters of optimized AQM mechanisms (e.g. GRED) in Discussions on setting RED parameters, Nov.
1997. http://www.aciri.org/floyd/REDparameters.
the future and especially on the reasons behind the behavior [9] S. Floyd. Recommendations on using the gentle variant TD exhibits significant dependency on traffic variability of RED, Mar. 2000. http://www.aciri.org/floyd/red/ concerning average queueing delay and its standard devia- tion. In lightly loaded scenarios with FTP traffic TD fre- [10] S. Floyd and V. Jacobson. Random Early Detection Gate- quently drops packets within a short time-window, causing ways for Congestion Avoidance. IEEE/ACM Transactions global synchronization. Our performance evaluation shows on Networking, 1(4):397–413, Aug. 1993.
[11] C. Hollot, V. Misra, D. Towlsey, and W. Gong. A control that global synchronization causes a high standard deviation theoretic analysis of RED. In Proceedings of the IEEE Info- of queueing delay, but the effect on TCP goodput is negli- gible. Additionally, for Web traffic and for medium to high [12] G. Iannaccone, M. May, and C. Diot.
load scenarios with FTP traffic, global synchronization dis- performance with active queue management and drop from appears with TD and the standard deviation of the queueing tail. Technical Report TR01-ATL-012501, Sprint ATL, Jan.
delay decreases in case the load increases.
In total, our evaluation does not show superiority of RED [13] V. Jacobson. Congestion Avoidance and Control. Computer over TD. Thus ISPs currently do not have an incentive to Communication Review, 18(4):314–329, Aug. 1988. Pro- migrate from TD to RED, given the complexity of RED pa- ceedings of the Sigcomm ’88 Symposium in Stanford, CA,August, 1988.
rameter setting. GRED performs reasonably well in all sce- [14] V. Jacobson. Modified TCP Congestion Avoidance Algo- narios but queueing delay and the standard deviation of the rithm, Apr. 1990. end2end-interest mailing list.
queueing delay still depend on the load. Generally speak- [15] V. Jacobson, K. Nichols, and K. Poduri. RED in a different ing, all queue management mechanisms perform well in light. Technical report, Sept. 1999.
certain scenarios but sub-optimal in others. Thus the de- [16] D. Lin and R. Morris. Dynamics of random early detection.
velopment of new active queue management mechanisms In Proc. SIGCOMM 97 Conference, 1997.
[17] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. RFC can still be considered as a challenge for the research com- 2018: TCP selective acknowledgment options, Oct. 1996.
[18] M. May. Performance Evaluation of recent/new QoS Mecha- nisms in the Internet. PhD thesis, Universit´e de Nice, Sophia References
[19] M. May, J. Bolot, C. Diot, and B. Lyles. Reasons not to de- ploy RED. In Proc. of 7th. International Workshop on Qual- [1] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and ity of Service (IWQoS’99), London, pages 260–262, June W. Weiss. RFC 2475: An architecture for differentiated ser- [20] R. Morris. TCP behavior with many flows. In IEEE Inter- [2] B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, national Conference on Network Protocols, Oct. 1997.
D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, [22] K. Ramakrishnan and S. Floyd. RFC 2481: A proposal to management and congestion avoidance in the Internet, Apr.
add Explicit Congestion Notification (ECN) to IP, Jan. 1999.
[23] L. Rizzo. Dummynet: a simple approach to the evaluation on network protocols. ACM Computer Communication Re- oped in [26], 2000. http://www.salzburgresearch.at/ [24] T.J.Ott, T.V.Lakshman, and L.Wong.
[4] M. Christiansen, K. Jeffay, D. Ott, and F. Smith. Tuning RED. In Proc. IEEE Infocom, San Francisco, CA, Mar.
RED for web traffic. In Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, pages 139–150, Sept. 2000.
ANSNET. Computer Communication Review, 24(5):45–60, [5] D. Clark and W. Fang. Explicit allocation of best effort packet delivery service. IEEE/ACM Transactions on Net- [26] T. Ziegler, C. Brandauer, and S. Fdida. A quantitive model working, 6(4):362–373, 1998.
for parameter setting of RED with TCP traffic. In Proceed- [6] A. Feldmann, A. C. Gilbert, P. Huang, and W. Willinger.
ings of the Ninth International Workshop on Quality of Ser- Dynamics of IP traffic: A study of the role of variability and vice (IWQoS), 2001, Karlsruhe, Germany, to appear, 2001.
the impact of control. In Proceedings of ACM SIGCOMM [27] T. Ziegler, S. Fdida, and C. Brandauer. Stability of RED ’99, pages 301–313, 1999.
with two-way TCP traffic. In IEEE ICCCN, Las Vegas, Oct.
[7] V. Firoiu and M. Borden. A study of active queue man- agement for congestion control. In Proceedings of IEEE

Source: http://martin.may.free.fr/biblio/iscc2001-spu-tail_drop.pdf