Algorithm 13 describes the pseudo-code of the SFB scheme.
1.3.3
XRED
XRED is proposed by Hutschenreuther and Schill in [53] with the aim to reduce bandwidth waste for MPEG video transmission over routers using AQM. Indeed, RED drops packets without a distinction between packets. Some packets may be more crucial than the others. For example, the loss of few packets generated by a MPEG video application can make useless the entire application frame at destination. This results in a waste of the router bandwidth.
The idea of XRED is to describe a packet by three parameters: F low ID for traffic flow, ADU ID for specified application data unit, and Content P riority for packet content with different priority. A list that records these three parameters is maintained at the router.
When MPEG frames are fragmented into IP packets, XRED assigns each packet with F low ID, ADU ID and Content P riority. When a packet is dropped, its F low ID, ADU ID and Content P riority are written into the list, and each arriving packet is checked by com- paring its parameters with the stored parameters. The packet is discarded if its variable Content P riority is lower than the one in the list.
Although simulation results show that XRED reduces bandwidth waste, XRED has the following disadvantages XRED needs extra fields in the IP header. Moreover, it needs to record three parameters for each application flow, giving rise to scalability problems. Finally, it needs extra actions to write and read list and compare the three parameters, which might consume a significant amount of computer power at the router.
Among others per-flow accounting schemes that is not described in this chapter, is the Fair buffering RED (FB-RED) scheme which is proposed by Kim and Lee in [63] with the aim to address the problem of fair bandwidth sharing between flows.
1.4
RED with class-based threshold
1.4.1
Class Based Threshold RED (CBT-RED)
To solve the UDP-TCP fairness problem of RED, Class Based Threshold RED (CBT- RED) has been proposed by Parris et al. in [86]. CBT-RED sets the queue thresholds according to the traffic type and its priority. The UDP traffic is tagged and has its own drop threshold, which is different from that of the TCP traffic. The TCP traffic is, thus, protected from the UDP traffic. CBT-RED configures the RED parameter according to the traffic type.
Chapter 1. RED and some of its variants
1.4.2
Balanced RED (BRED)
As an extension to FRED [70], Balanced RED (BRED) has been proposed by Anjum and Tassiulas [5] with the aim to achieve fair bandwidth among TCP and UDP traffic. The principle of BRED is to regulate the bandwidth of a flow by keeping per-active flow accounting. This is done by dropping packets preventively so that the non-adaptive traffic that steal more bandwidth from the adaptive flows are penalized.
For this purpose, BRED introduces five global control variables that are used to control the bandwidth attained:
• Wm: the maximum number of packets that every flow is allowed to have in the buffer.
• li: minimum number of packets that flow i can have in the buffer before its packets
start being dropped with probability pi, for i = 1, 2.
• pi: probability to drop a packet from a flow i when li is reached for this flow.
These parameters are set as follows:
l1 = βl2 , l2 = B 2 N , p2 = N N + 10 and p1 = p2 10 ,
where β is a constant (0 < β ≤ 1) and N is an estimate of the number of flows active at
the gateway. It is calculated as:
N ← (1 − ω) N + ωNactive , (1.27)
and Nactive is the measure of the number of flows having at least one packet in the buffer.
The parameter ω is set to 0.02.
The decision to drop or accept an incoming packet is mainly based on qleni and gapi
which gives a step drop function. The variable gapi prevents successive multiple drops that
are harmful to adaptive flows. The three thresholds l1, l2 and Wm, on per-flow queue length
qleni divide the space of qleni into four regions: (0, l1), (l1, l2), (l2, Wm) and (Wm,∞):
• If qleni ∈ (Wm,∞) then the packet is definitely dropped.
• If qleni ∈ (l2, Wm) and gapi > l2, then the packet is dropped with probability p2.
• If qleni ∈ (l1, l2) and gapi > l1, then the packet is dropped with probability p1.
• If qleni ∈ (0, l1), then the packet is accepted.
1.4. RED with class-based threshold
qleni and gapi are increased if the packet is accepted. qleni is decreased for each
departure of a packet belonging to flow i.
Although BRED can minimize the differences in the bandwidth obtained by each flow, it needs to maintain the flow states, which means that its implementation complexity is proportional to the router buffer size.
1.4.3
RED In-Out (RIO)
Another variant of RED proposed for DiffServ (Differentiated Service) is RIO (RED In Out queue) [26, 27] where “in” stands for packets that are in compliance with the connection agreement and “out” stands for packets that are not. RIO has different dropping thresholds for each predefined traffic class. The lowest minimum and maximum thresholds are given to best effort packets. AF (Assured Forwarding) and EF (Expedited Forwarding) marked packets have lowest drop probability. However, in case of a non compliance with the SLA (Service Level Agreement), an AF packet is reclassified as best-effort class packet whereas an EF packet is dropped. EF packets have the advantage of using a separate priority FIFO queue. Whereas the AF packets share a RIO queue with best effort packets.
M inIn M axIn
PM axIn
P (drop Out)
M inOut M axOut Avgtotal
PM axOut
1
Figure 1.5: RIO drop functions
RIO uses the same mechanism as in RED and retains all the attractive attributes of RED (reduces the queue length, increases the throughput, avoids global synchronization). However, it has two different configuration thresholds for “in” and “out” packets in order to discriminates against Out packets in time of congestion that is to drop more aggressively “out” packets as compared to “in” packets. Hence, RIO uses twin RED algorithms for dropping packet, one for Ins and one for Outs. By choosing the parameters for respective algorithms differently, RIO is able to preferentially drop Out packets. There are three
parameters for each of the twin algorithms. With the three parameters M inIn, M axIn
Chapter 1. RED and some of its variants
Algorithm 14 BRED
/* Notations : */ /* – B: buffer size. */
/* – Nactive: measure of the number of flows having packets in the buffer. */
/* – l1: minimum number of packets that a flow can have in the buffer before its packets
start being dropped with probability p1. */
/* – l2: number of packets that a flow can have in the buffer before its packets start
being dropped more aggressively with probability p2 > p1. */
/* – Wm: maximum number of packets that the flow is allowed to have in the buffer.
*/
/* – qleni: number of pack ets from flow i in the buffer. */
/* – gapi: number of packets accepted from flow i since last packet dropping from flow
i. */
⇒ At each arrival of packet from flow i:
if it is the first packet of flow i (flow i is a new flow) then
qleni = 0.
gapi = 0.
Nactive = Nactive+ 1
end if
if qleni ≥ Wn or buffer overflow then
Drop packets.
else if Wm > qleni > l2 and gapi > l2 then
Drop packets with probability p2.
else if l2 > qleni > l1 and gapi > l1 then
Drop packet with probability p1.
else if qleni ≤ l1 then
Accept packet.
qleni = qleni+ 1.
gapi = gapi+ 1.
end if
⇒ At each departure of packet from flow i:
qleni = qleni − 1.
if qleni = 0 then
Nactive = Nactive− 1.
gapi = 0.
end if
⇒ At each packet drop from flow i:
gapi = 0.