74 CHAPTER 4 ACTIVE QUEUE MANAGEMENT 4.1 INTRODUCTION QoS in the existing and emerging applications in the Internet has been a big challenge to the Internet Programmer. Real time applications such as audio/video conversations and on demand movies are interactive, have delay constraints or require high throughput. There were many mechanisms proposed in the past to enable the internet to support applications with varying service requirements. These include admission control, queue management algorithms and scheduling. Admission control is meant to prevent network overload so as to ensure service for applications already admitted. It is deployed at the network edges where a new flow is either admitted, when network resources are available or rejected otherwise. Active queue management has been proposed to support end-to-end congestion control in the Internet. The aim is to anticipate and signal congestion before it actually occurs. Scheduling determines the order in which the packets from different flows are served. A network with quality of service has the ability to deliver data traffic with a minimum amount of delay in an environment in which many users share the same network. Low-priority traffic is "drop eligible," while high-priority traffic gets the best service. However, if the network does not have enough bandwidth, even high-priority traffic may not get through.
28
Embed
CHAPTER 4 ACTIVE QUEUE MANAGEMENT - Shodhgangashodhganga.inflibnet.ac.in/bitstream/10603/25554/9/09... · 2018. 7. 2. · 4.3 ACTIVE QUEUE MANAGEMENT (AQM) An implementation of proposed
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
74
CHAPTER 4
ACTIVE QUEUE MANAGEMENT
4.1 INTRODUCTION
QoS in the existing and emerging applications in the Internet has
been a big challenge to the Internet Programmer. Real time applications such
as audio/video conversations and on demand movies are interactive, have
delay constraints or require high throughput. There were many mechanisms
proposed in the past to enable the internet to support applications with varying
service requirements. These include admission control, queue management
algorithms and scheduling. Admission control is meant to prevent network
overload so as to ensure service for applications already admitted. It is
deployed at the network edges where a new flow is either admitted, when
network resources are available or rejected otherwise. Active queue
management has been proposed to support end-to-end congestion control in
the Internet. The aim is to anticipate and signal congestion before it actually
occurs. Scheduling determines the order in which the packets from different
flows are served.
A network with quality of service has the ability to deliver data
traffic with a minimum amount of delay in an environment in which many
users share the same network. Low-priority traffic is "drop eligible," while
high-priority traffic gets the best service. However, if the network does not
have enough bandwidth, even high-priority traffic may not get through.
75
Traffic engineering, which enables QoS, is about making sure that the
network can deliver the expected traffic loads.
Multimedia applications require better Quality of service which can
be provided by properly classifying and scheduling the packets, shaping the
Traffic, managing the bandwidth, and reserving the resources. All these
techniques require the fundamental task packet classification at the router, to
categorize the packets into flows. The end-to-end congestion control in the
Internet requires some form of feedback information from the congested link
to the source of data traffic, so that they can adjust their rates of sending the
data. Therefore explicit feedback mechanism, such as Active Queue
Management algorithms can be used in the network .
A QoS-enabled network is composed of various functions for
providing different types of service to different packets such as rate controller,
classifier, scheduler, and admission control. The scheduler function of them
determines the order in which packets are processed at a node and/or
transmitted over a link. The order in which the packets are to be processed is
determined by the congestion avoidance and packet drop policy (also called
Active Queue Management) at the node. Here D-QoS can be applied
regardless of existing network settings.
As the volume of traffic and number of simultaneously active flows
on Internet backbones increases, the problem of recognizing and addressing
congestion within the network becomes increasingly important. There are two
major approaches to managing congestion. One is to manage bandwidth
through explicit resource reservation and allocation mechanisms. The other
approach is based on management of the queue of outbound packets for a
particular link. This latter approach has recently become the subject of much
interest within the Internet research community. For example, there is an
increasing focus on the problem of recognizing and accommodating “well-
76
behaved” flows that respond to congestion by reducing the load they place on
the network.
We are investigating a different approach: the development of
active queue management policies using network processor that attempt to
balance the performance requirements of continuous media applications.
Specifically, we are experimenting with extensions to the RED queue
management scheme for providing better performance for UDP flows without
sacrificing performance for TCP flows. Thus, independent of the level of TCP
traffic, a configurable number of tagged UDP connections are guaranteed to
be able to transmit packets at a minimum rate.
The goals of our approach, termed Class-Based Thresholds (CBT),
are similar to other schemes for realizing “better-than-best-effort” service
within IP, including packet scheduling and prioritization schemes such as
Class-Based Queuing (CBQ). While we recognize packet scheduling
techniques such as CBQ as the standard by which to measure resource
allocation approaches, we are interested in determining how close we can
come to the performance of these approaches using thresholds on a FIFO
queue rather than scheduling. Moreover, we believe our design, using an
active queue management approach to be simpler and more efficient than
other schemes.
4.2 QUEUE MANAGEMENT TECHNIQUES
Queuing Mechanism
To implement QoS in the network nodes, the major function that
must be addressed is queuing mechanism. Queuing is a process of storing
packets for subsequent processing [Ferguson and Huston, 1998]. Typically,
queuing occurs when packets are received by a network node and also occurs
prior to forwarding the packets to the next node. Thus, the network is
77
considered to operate in a store-and-forward manner. Queuing is one of the
key components for achieving QoS. Even though the queuing may happen
twice on a network node, the one for output traffic is normally focused on
since it has crucial role in traffic management and QoS related issues.
Queuing mechanism can be used to isolate the traffic allowing a level of
control over those traffic classes, thus, suitable for traffic management.
Apart from the queuing mechanism used, the queue length which is
a configurable characteristic for a queue also plays an important role in
providing QoS. Correct configuration on the queue length is difficult due to
the randomness of network traffic. A queue length which is too deep results in
long, and possibly unacceptable, delay, jitter, which may consequently lead to
failure of data transmission. On the other hand, if a queue length is too
shallow, the network may exhibit packet drops that, of course, affect the
performance of the applications. This section presents a number of queuing
mechanisms that are used for QoS implementation in this study.
First-In, First-Out (FIFO)
FIFO is also known as First-Come, First-Served (FCFS). It is
considered a standard method for store-and-forward mechanism. It provides
no concept of priority or classes of traffic. It operates on a single queue where
the transmission of packets departing the queue is in the same order as their
arrival order regardless of bandwidth consumption or the associated delays.
FIFO is said to have a tail drop characteristic as an arriving packet is dropped
when the queue is full. Since all traffic is treated equally, non-responsive
traffic can fill a big part of the queue and consume a large portion of the
available buffer, and also bandwidth. Non-responsive traffic refers to the
traffic of applications that do not have data rate adaptation scheme, usually
those running over UDP. As more bandwidth is consumed by these
applications, other traffic may be dropped due to the completion of the queue.
78
FIFO can be effectively used on a queue with high transmission capacity,
resulting in little and acceptable delay and minimal congestion. However, it
provides no guarantee on traffic differentiation and, therefore, cannot be used
for QoS implementation.
Class-Based Queuing (CBQ)
CBQ [Floyd and Jacobson 1995] is a traffic management algorithm
developed by the Network Research Group at Lawrence Berkeley National
Laboratory, as a variant of priority queuing. This mechanism divides traffic
into a hierarchy of classes and specifies how they share bandwidth in a
flexible manner. Each class has its own queue and can represent an individual
flow or an aggregation of flows. This algorithm intends to prevent complete
resource denial to any particular class of service.
CBQ has two key attributes associated with each class, priority
level and borrowing property. Priority levels allow higher priority queues to
be serviced first within the limits of their bandwidth allocation so that the
delay for time-sensitive traffic classes is reduced. Borrowing property of a
class is a mechanism used to distribute excess bandwidth. A class with
borrowing property may borrow bandwidth, according to the hierarchy, when
it needs more bandwidth. Available bandwidth is granted to higher priority
classes before lower priority ones. The flexibility feature of CBQ, however,
has posed additional overhead that may affect queuing performance.
Absolute Priority Queuing
In absolute priority queuing (Figure 4.1), the scheduler prefers
queues with high priority, forwarding packets from queues with lower priority
happens only when the higher priority queues are empty. Therefore, the
packets put into the queue with the highest priority achieve the best service,
79
while packets sent to queues with lower priority have to be satisfied with the
left resources. The basic working mechanism is as follows: the scheduler
always scans the queues from their highest to lowest priority and transmits
packets if available. Once a packet has been sent, the scheduler starts again at
the queue with the highest priority. This queuing mechanism is useful to give
a specific flow or service class the absolute priority over other traffic, which
is important for bandwidth and delay critical data.
Figure 4.1 Absolute priority queuing
As long as high priority packets do not exceed the outgoing
bandwidth, the packets are forwarded with a minimal delay. Setting up
Differentiated Services networks, this algorithm might be used to provide an
expedited forwarding (EF) service. Of course the expedited forwarding traffic
has to be policed as misbehaving EF senders would be able to completely
starve the bandwidth of traffic classes with less priority.
4.3 ACTIVE QUEUE MANAGEMENT (AQM)
An implementation of proposed active queue management system
for enforcing QoS guarantees can make use of the following NP hardware
support. Hardware-supported flow control is invoked when a packet is
enqueued in ingress and egress. The transmit probabilities used for flow
80
control are taken from a table stored in fast access memory, i.e., the Transmit
Probability table. The key to index into the transmit probability table is
composed of packet header bits (e.g. IETF DiffServ code point). The access
to these header bits is supported by a header parser hardware-assist.
Furthermore, detailed flow accounting information about individual ordered
loads is provided via hardware counters. Such counters as well as queue level
indicators and queue depletion indicators at various locations in a NP can be
used to update the transmit probability memory (e.g. ingress general queue,
ingress target NP-queue, egress fl queue, egress port queue). Traditional
active queue management systems use general queue levels to determine
transmit probabilities. However, such an approach is not feasible for high-
speed routers with significantly varying ordered loads.
4.3.1 Application of AQM to Multimedia Applications
Our AQM provides preferential treatment to multimedia
applications by providing lower packet loss using strategically placed packet
marking and active queue management functions. Placement of packet
marking and AQM is recommended at particular places where congestion can
occur. Most notably those places could be at bottleneck links between Internet
Service Providers (ISP’s), in regional networks (e.g. lower tier ISP’s,
corporate networks, or non-profit regional educational networks) or in some
types of access networks (e.g. DSL, cable modem or wireless).
The implementation of AQM for high priority flow seeks to drop
the packets of low priority flow as much as needed to allow as much high
priority traffic as possible to proceed through the router. The goal is to
provide lower packet loss for high priority traffic so that multimedia
communications can proceed more dependably. It should be noted, however,
that multimedia traffic in general does not need to have better delay or jitter
performance than normal traffic.
81
Figure 4.2 Dropping probability for different traffic flows
The use of AQM, therefore, is meant to create lower packet loss for
high priority traffic by acting as a filtering mechanism to perform prioritized
packet discarding (Fig. 4.2). The filtering also seeks, however, to provide the
best service possible to low priority traffic by not unnecessarily favoring
emergency or high priority traffic.
4.3.2 Differentiated Services Traffic Conditioning Using Network
Processor
QoS guarantees for diversified user traffic can be achieved in two
ways: (1) using overlay networks with bandwidth over provisioning, or (2)
using intelligent traffic management functions. Most service providers build
their networks today using the first approach, in which they assign different
types of traffic to different networks (e.g., voice and data) and provide
sufficient additional bandwidth in the network to avoid the need for QoS
mechanisms. This is, however, an expensive solution. The second approach
involves using intelligent traffic management functions such as classification,
metering, marking, policing, scheduling, and shaping.
82
For the latter approach, a NP may include specialized-units to
support some of these functions in hardware (Figure 4.3).
Figure 4.3 Network processor support for traffic management
A packet classifier classifies packets based on the content of some
portion of the packet header according to some specified rules and identifies
packets that belong to the same traffic flow. A predefined traffic profile then
specifies the properties (such as rate and burst size) of the selected traffic flow
by the classifier. The traffic profile has preconfigured rules for determining
whether a packet conforms to the profile.
A traffic meter measures the rate of traffic flow, selected by the
classifier, against the traffic profile to determine whether a particular packet is
conforming to the profile.
A marker marks a packet based on the metering result. The marker
has rules for marking packets based on whether they exceed the contracted
traffic profile. There are several standards and proprietary schemes for packet
marking. For example, Diffserv defines a single rate three color marker
(srTCM) which marks IP packets either green, yellow or red according to
three traffic parameters: Committed Information Rate (CIR), Committed
Burst Size (CBS), and Excess Burst Size (EBS). The srTCM-marking
Classifier Meter Marker PolicerPacket Flow
Ingress
Protocol Processing SchedulerShaper
Egress
83
scheme marks an IP packet green if it does not exceed CBS, yellow if it
exceeds CBS but not EBS, and red otherwise. These markings are then used
to implement congestion control and queuing policies as established by the
network administrator.
During periods of congestion, the policer discards packets entering
the NP input queues. Packets are discarded in a fair fashion based on their
marking (e.g., red packets first, yellow packets next and green packets last)
when the input queues exceed some threshold values. As a result, fairness of
resource usage is achieved since conforming-traffic is forwarded and non-
conforming traffic is discarded. A congestion avoidance algorithm can be
used for IP flows to control the average size of input queues. Such schemes
start discarding packets from selected traffic flows when the input queues
begin to exceed some threshold values.
Packet scheduling schemes are used to intelligently control how
packets get serviced once they arrive at the NP output ports. To meet the
various QoS requirements of a multi-service platform, a scheduler may
support a mix of flexible queuing disciplines
The shaper smoothes the traffic flow exiting the system in order to
bring the traffic flow into compliance with the contracted traffic profile. This
also allows the network administrator to control the traffic rate of an outbound
interface.
4.3.3 Class-Based Thresholds
In this Class-Based Thresholds (CBT) algorithm, we define a set of
traffic classes: responsive (i.e., TCP), multimedia, and other. For each class a
threshold is specified that limits the average queue occupancy by that class. In
84
CBT, when a packet arrives at the router it is classified into one of these
classes. Next, the packet is enqueued or discarded depending on that class's
recent average queue occupancy relative to the class's threshold value. Our
approach is to isolate high priority flows from the effects of all other flows by
constraining the average number of low priority packets that may reside
simultaneously in the queue. We also wanted to isolate classes of low priority
traffic from one another, specifically isolating continuous media traffic from
all other traffic. To do this we tag continuous media streams before they reach
the router so that they can be classified appropriately. These flows are either
self-identified at the end-system or identified by network administrators.
4.3.4 Packet Classification
DiffServ redefines and restructures the Type of Service (TOS) octet
of the IPv4 packet header or the Traffic Class octet in IPv6’s. The field is
called a differentiated services field or DS field. In DS field, it contains a 6-bit
Differentiated Services Code Point (DSCP) and a currently 2-bit unused field.
DSCP is mainly used for packet processing (Figure 4.4) in the microengine.
Details on the layout of these fields, as shown in Figure 4.5, are standardized
and specified.
Figure 4.4 Packet processing in NP
Packet classification is performed on each packet by using either
only the values of the code point or a combination of the code point with one
or more header fields, which are source address, destination address, protocol
85
ID, source port number, destination port number and other information such
as incoming interface.
Figure 4.5 Packet classification based on TOS value
Packets from various flows are classified into a set of predefined
classes according to the value of their code points. The semantic of each code
point can be taken from a set of mandatory values or it can be based on local
meaning specified by network administrators.
4.3.5 Traffic Class Identification
Statistics are maintained for these classes of traffic and their
throughput are constrained during times of congestion by limiting the average
number of packets they can have enqueued. Untagged packets are likewise
constrained by a (different) threshold on the average number of untagged
86
packets enqueued. These thresholds only determine the ratios between the
classes when all classes are operating at capacity (and maintaining a full
queue). When one class is operating below capacity other classes can borrow
that classes unused bandwidth. Whenever a packet arrives, it is classified as
being either tagged (continuous media), or untagged (all others). For the
other classes, the average number of packets enqueued for that class is
updated and compared against the class threshold. If the average exceeds the
threshold, the incoming packet is dropped. If the average does not exceed the
threshold then the packet is subjected to the RED discard algorithm. Thus a
low priority packet can be dropped either because there are too many packets
from its class already in the queue or because the RED algorithm indicates
that this packet should be dropped. Priority packets are only dropped as a
result of performing a RED discard test. In all cases, although packets are
classified, there is still only one queue per outbound link in the router and all
packets are enqueued and dequeued in a FIFO manner.
RED discard test: In addition, the weighted average queue length
used in the RED algorithm is computed by counting only the number of high
priority packets currently in the queue. This prevents an increase in
multimedia traffic from increasing the drop rate for a conformant tagged flow
and it prevents the presence of the tagged and untagged packets from driving
up the RED average, resulting in additional drops of priority packets. For
example, with thresholds of 10 packets for tagged and 2 packets for untagged
traffic, these packets alone can maintain an average queue size of 12. Since
these flows do not respond to drops, the resulting probabilistic drops only
affect priority traffic, forcing priority flow to constantly respond to
congestion. Removing these packets from the average reduces their impact on
the high priority traffic. Thus when high-bandwidth low priority flows are
active our first variant reduces to reserving high priority flows a minimum
87
number of queue slots and performing the RED algorithm only on them. In
this way, we increase the isolation of the classes.
Table 4.1 CBT with RED for all flows
Queue Size(100)
Queue Size(200)
Queue Size(300)
Queue Size(500)
Average
Queue Length 25 46 69 108
Percentage of
Dropped Packets5.5% 4.6% 2.9% 1.3%
We refer to the main CBT algorithm described above in Table 4.1
as “CBT with RED for all flows.” We also consider the effect of not
subjecting the low priority flows to a RED discard test. The motivation here
comes from the observation that since the low priority flows are assumed (in
the worst case) to be unresponsive, performing a RED discard test after
policing the flow to occupy no more than its maximum allocation of queue
slots provides no benefit to the flow and can penalize a flow even when that
class is conformant. While the additional RED test may benefit high priority
flows, they are already protected since the low priority flows are policed.
4.3.6 QoS Provisioning
The simplest way to provide useful QoS is for each queue to have
an aggregate minimum bandwidth guarantee min and an aggregate bandwidth
maximum max. Hence 0 - min - max. If multiple minimum band-width
guarantees are represented by constituent flows in a queue, then these must be
summed to achieve a queue minimum. As network end-to-end paths with
88
guarantees are added or deleted, ensuring the guarantees of the minimums at
each NP in the network is the complex yet hidden work of network control.
The implemented active queue management system uses modest
amounts of control theory to adapt transmit probabilities to current ordered
loads. A signal is declared that defines the existence of excess bandwidth.
This signal can use flow measurements, queue occupancy, rate of change of
queue occupancy, or other factors. If there is excess bandwidth, then flows
that are not already at their maxs are allowed to increase linearly. Otherwise,
the rates allocated to flows not already below their mins must decrease
exponentially.
For example, let us suppose four strict-priority flows in egress are
all destined to the same 100 Mbps target port as shown in Table 4.2. All
bandwidth units are in Mbps. If the four flows offer rates of 15, 15, 50, and
100 (so sum = 180), then the correct allocation should be: all Flow0, Flow1,
and Flow2 traffic should be transmitted, and of Flow3 one fifth of the packets
should be transmitted (packets selected randomly). Furthermore, the above
allocation should be reached quickly and with low queue occupancy.
Table 4.2 Example of flows for bandwidth allocation
Flow label Type Minimum Maximum Priority
Flow0 real-time 10 30 0 (High)
Flow1 Non-real-time 20 40 1
Flow2 Non-real-time 0 100 2
Flow3 Non-real-time 0 100 3 (Low)
89
There are virtually no costs for implementing the active queue
management system in the data plane of the NP because the header parser
hardware-assist and hardware flow control support can be configured
according to the new scheme. The implementation costs in the control plane
are about 300 cycles to update a single transmit probability value. This update
is triggered in fixed time intervals for each queue at each output port. These
costs cover line-speed forwarding and normal control operation. It was
possible to make this advanced networking function swiftly operational as a
standard feature on the NP which demonstrates the flexibility of NPs.
4.4 SIMULATION STUDY
The Workbench of IXP2400 provides packet simulation of media
bus devices as well as simulation of network traffic. There is a feature under
the packet simulation called Packet Simulation Status, shown in figure 4.6
enables the observation of the number of packets being received into the
media interface and number of packets being transmitted from the fabric
switch interface.
Figure 4.6 Packet Simulation status
Multimedia streams are artificially simulated with UDP flows since
voice and video applications use UDP rather than TCP. Traffic generated in
this work consists of RTP/UDP packets, UDP packets (with large TTL and
90
with less TTL) and TCP packets. All these packets are uniformly distributed
in the traffic. Traffic is generated with a constant rate of 1000Mb/s and inter-
packet gap is set to 96 ns.
To make sure that various traffic streams (Figure 4.7) are not
synchronized, each flow begins its transmission at a random time within the
first 40 msec. The QoS setting in D-QoS is automatically adjusted to offer the
interruption according to the buffer capacity of the flows.
Figure 4.7 Creating various traffic streams
When voice and video packets need to pass through router
(IXP 2400) will be treated and processed at the highest priority as it is real
time traffic. The first priority will be for the Expedited Forwarding (EF)
which handles real time application packets. This minimize the packet delay
for the real-time data packets in IPv6 DiffServ Network to maximize the
throughput of the data like voice, video etc in which delay is not tolerable.
When EF traffic got some break then second priority for Assured Forwarding
(AF) traffic will be forwarded.
In this process both incoming traffic and stored packets in the
memory will be moved if there is any. The third priority packets are buffered
accordingly, when there are no packets or traffic for EF or AF then the
packets for third priority means best effort will be forwarded.
91
The simulator is configured to generate and inject packet streams to
ports 0 and 1 of the device 0. Packet Receive Microengine has been interfaced
with the Media Switch Fabric Interface (MSF). The packets are injected
through Media switch Fabric Interface and Receive Buffer (RBUF)
reassembles incoming mpackets (packets with length 64 bytes). For each
packet, the packet data is written to DRAM, the packet meta-data is written to
SRAM. The Receive Process is executed by microengine (ME0) using all the
eight threads available in that microengine. The packet sequencing is
maintained by executing the threads in strict order.
The packet buffer information is written to a scratch ring
(Figure 4.8) for use by the packet processing stage communication between
pipeline stages is implemented through controlled access to shared ring
buffers as shown in the code given below.
Figure 4.8 Packet information in Scratch ring
Code for scratchpad put buffer
void scratch_ring_put_buffer( unsigned int ring_number, ring_data_t data) {