The AQM algorithm runs on a router, which updates and feedbacks congestion information to end-users. The feedback is usually in the form of packet loss, delay, or marking. There is a very large body of AQMs proposed, and I will just describe few common AQMs in this subsection.
2.2.1 Droptail
Droptail is the simplest AQM scheme in the current Internet. It is just a first-in-first- out(FIFO) queue with limited capacity, and it simply drops any incoming packets when the queue is full. Since it is simple and easy to implement, Droptail is the dominant AQM in the current Internet. This FIFO queue helps to achieve better link utilization and absorbs the bursty traffic.
The congestion information in a Droptail queue is updated by the queueing process and
is represented by the size of the backlog buffer. The delay-based TCP algorithms, e.g., TCP Vegas and FAST, receive this information by sensing the changes in the round-trip delay. The dynamics of FAST TCP will be studied in Chapter 4 using Droptail routers with sufficient buffer.
For loss-based sources, the Droptail queue sends back one bit of information by a packet drop, which indicates that the router buffer is full and the network is congested. When working with TCP Reno, Droptail routers have two drawbacks: the lock-out and the full- queue phenomena, which are pointed out in Braden et al. [17]. The lock–out phenomenon involves a single or a few sources that monopolize the bandwidth. This situation is usually the result of synchronization [55, 117]. The full-queue phenomenon refers to the effect that the queue can be full (or almost full) for long periods of time, which produces large end-to-end delays.
One possible solution to overcome these problems is to detect congestion early and to convey congestion notification to sources before queue overflow. We describe one such solution below.
2.2.2 Random Early Detection (RED)
The Random Early Detection algorithm, or RED, is proposed by Floyd and Jacobson [41] to solve the synchronization and full queue problems of Droptail. In contrast to Droptail that drops packets deterministically when the buffer is full, the RED algorithm drops arriving packets probabilistically based on average queue size. The packet is dropped randomly to break up synchronized processes that lead to the lock-out phenomenon, and RED controls the average queue size to avoid queue overflow.
There are two components in the RED algorithm. The first is the estimation of average queue size using the exponential weighted average, which can also be interpreted as a low pass filter to get rid of noise. The other part of the algorithm decides whether to drop an incoming packet. There are three RED parametersminth,maxth, andmaxpcontrolling the dropping probability as shown in Figure 2.2. When the average queue size is less than the minimum threshold minth, the dropping probability is zero. When it exceeds
the maximum threshold maxth, all the incoming packets will be dropped. When it is in between, packets will be dropped with a probability that varies linearly from 0 tomaxp.
maxth avg. queue size p
minth maxp
Figure 2.2: RED dropping function.
The RED can also mark the incoming packets instead of dropping them with the deploy- ment of Explicit Congestion Notification (ECN) [131] to prevent packet loss and improve throughput. The basic idea of ECN is to give the network the ability to explicitly signal TCP sources of congestion using one additional bit in the IP packet header and to have the TCP sources reduce their transmission rates in response to the marked packets.
The dynamics of Reno/RED systems will be studied in details in Chapter 3. It is shown that the system becomes unstable when the delay increases or when the link capacity in- creases. It is very difficult to configure the RED parameters to achieve better performance.
There has been a large body of AQM schemes proposed recently. Some notable exam- ples include, Stabilized RED [123], PI controller [58], REM [5] , AVQ [86], BLUE [35], etc.
2.2.3 CHOKe
CHOKe [126], which stands for “CHOose and Keep for responsive flows, CHOose and Kill for unresponsive flows”, is proposed by Pan et al. in 2001. It aims to penalize the un- responsive flows (e.g., UDP sources), to protect the rate-adaptive flows (e.g., TCP sources), and to ensure fairness.
The scheme, CHOKe, is particularly interesting in that it does not require any state information and yet can provide a minimum throughput to TCP flows. The basic idea of
CHOKe is explained in the following quote from [126]:
When a packet arrives at a congested router, CHOKe draws a packet at random from the FIFO (first-in-first-out) buffer and compares it with the arriving packet. If they both belong to the same flow, then they are both dropped; else the randomly chosen packet is left intact and the arriving packet is admitted into the buffer with a probability that depends on the level of congestion (this probability is computed exactly as in RED).
The surprising feature of this extremely simple scheme is that it can bind the bandwidth share of UDP flows regardless of their arrival rate.
Its queue characteristics and the maximum throughput of unresponsive flows is studied in [143, 155, 145]. These results will be briefly covered in Section 7.2.