Content uploaded by Hendrik Christoffel Ferreira
Author content
All content in this area was uploaded by Hendrik Christoffel Ferreira on Feb 15, 2017
Content may be subject to copyright.
Content uploaded by Hendrik Christoffel Ferreira
Author content
All content in this area was uploaded by Hendrik Christoffel Ferreira
Content may be subject to copyright.
IEEE
AFRICON
2004 323
SCHEDULER PERFORMANCE EVALUATION AND THE
EFFECT
OF
AGGREGATION ON QOS IN
A
DIFFSERV
ENABLED NETWORK
J.J.
Smit.
H.C.
Ferreira
Department
of
Electrical and Electronic Engineering
Rand Afrikaans University
P.O.
Box
524, Auckland Park, 2006
South Africa
Tel:
37-1
1-
489-2463
Fax:
17-1
I-
489-2357
Email: johans@ing.rau.ac.za
ABSTRACr-Various network traffic models exist that
describe network traffic behaviour, hut no model
describes differential traffic treatment to such
an
extent
to he able
Io
relate the impact different rates has on the
various traffic classes. With computer neiwork
simulation, we evaluate four different standardized
PHBs,
namely
EF, AFI, AF2
and
BE.
The
PQ, SFQ,
SCFQ,
WFQ,
WF’Q+
and
LLQ
scheduling mechanisms
are analysed to find their performance in relation to
EF
traffic
as
well
as
the effects of different traffic
aggregation schemes on them. The
QoS
factors we focus
on are: one-way delay, queue lengths and inter-packet
delay variation. Network topologies are large and are
defined by various parameters, thus
our
simulations are
performed
using
acceptable bounded properties.
Index TermsQualily of Service, Service Rates,
Packet Delay, Scheduling,
QoS
mechanisms.
1.
INTRODUCTION
ith the recent convergence of data, voice and video
Wtraffic over networks such
as
the Intemet, a solution
is
required
to
provide Quality
of
Service
(QoS).
The lntemet
is
a network that only provided very simple
QoS,
called
Best
Eflort
(BE) Service which provided point-to-point data
delivery. The world
of
telecommunication is changing
rapidly, and with the introduction of
Voice
over
IP
(VolP)
and various other real-time commercial products, the need
and demand for guaranteed service is crucial. The
telecommunication industry
is
slowly migrating to IP
networks, thus the issues of differentiating service
is
not
bound to the lntemet only.
In
the industry, a telephone
service provider will need a Service class to provide low
delay and low jitter for applications such
as
IP Telephony,
Audio and Video Conferencing.
With the introduction of real-time applications on an 1P
network, the network infrastructure needed to be modified
to support this real-time
QoS.
The goal of QoS
is
to provide
guarantees on the ability of a network to deliver predictable
results. Elements of network performance within the scope
of
QoS
often include availability (uptime), bandwidth
(throughput), latency (delay), and error rate. The
Internet
Engineering
Task
Force
(IETF) has proposed various
QoS
mechanisms and services due
to
an increase
in
the demand
for
QoS.
These mechanisms are
Integrated Sewices/RSVP
(IntServ),
DiflerenriotedServices
(DiffServ)
[Z]
and MPLS.
The DiffServ framework
is
regarded by scientific
community
as
a scalable solution for supporting the
QoS
for
time-sensitive traffic. For our simulations,
as
the title
suggests, we are focusing in the study
on
the DiffServ
environment.
This paper is organized
as
follows.
In
Section
11,
we
briefly introduce
QoS
and the Differentiated Services
framework. Section 111 describes the simulation
methodology used.
In
Section
IV,
we describe our
simulations and present some performance analysis results.
Finally we conclude with Section
V,
our conclusion.
11.
QUALITY
OF SERVICE
A.
General
QoS’s
primary goals are to provide priority, make
measurement possible, guarantee and improve network
characteristics such as bandwidth, controlled latency and
jitter. Thus,
QoS
enables network providers to provide
better service to certain data flows. There exists a
misconception that the purchasing of more bandwidth will
alleviate the problem of high jitter and latency. If this was
the case then QoS management would become redundant.
Bandwidth hungry protocols such as TCP gradually increase
its
transmission rate (called
dow
stort),
which at the end
will consume the available bandwidth. Thus throwing
bandwidth at the problem will be a very short lived solution,
and the need for
QoS
management
is
evident.
In
various countries, the
PSW
networks are still circuit
switched networks, thus there was little or no need for
QoS.
Previously, the TCP/IP network was
a
best-effort network
since the protocol and network was mainly designed for
email and file transfer. The introduction of time-sensitive
0-7083-8605-1 /$17.00 2004 IEEE
324
IEEE
AFRICON
2004
0-7083-8605-1 l$17.00
2004
IEEE
applications such as VolP, multimedia conferencing etc.,
has made the need for QoS provisioning over an IP network
grow.
Different applications make use of the network, thus
various traffic types have converged onto a single TCPIIP-
based infrastructure. This convergence is taking place
in
an
attempt to reduce costs and complexity, improve efficiency,
and make way for new applications thereby giving access to
telecommunication to the masses. IP-based QoS
mechanisms are necessary to aid in the era of IP
convergence.
QoS is delivered by various mechanisms and
is
divided
into four different levels: Cell Level, Burst Level, Session
Level and General level. We are only focussing
on
the
Cell
Level mechanism that can be seen in Figure
I
[IS].
The
schedulers that we have focussed on thus far are
priority
queuing
(PQ)>
stochastic /air queuing
(SFQ),
self-clocked
/air
queuing
(SCFQ),
weighted fair queuing
(WFQ),
weighted fair squared queuing plus
(WF2Q) and
low
latency queuing
(LLQ).
..
Dp:
Figure
1:
QoS
Cell
Lwel
Mechanism
B.
Merrics
Various metrics exists for QoS. Delay and
loss
metrics
are important to the study. The delay metric consists
of
various components, such as network delay,
OS
delay,
application delay, look-ahead delay and hardware delay.
Network delay
is
of primary concern to us, since
it
describes
jitter, one-way delay and queuing delay.
In
OUT
research, we look at one-way delay as well as
inter-packet delay variation, which are better known as
jitter.
One-wq
Delqv
(OWD)
141
is intuitively defined as the
time a packet needs to be transmitted from a given source,
through the necessary nodes, until it is !My received by the
destination. The OWD can thus be described by
OWD,.=tD,
,=1
where Dj
is
the delay at node
j,
which at the end
is
the sum
of all the delay when moving from one node to the next.
The
lnstanlaneous Packer
Delay
Variation
(IPDV)
[6]
for
a pair of packets transmitted from the same source to the
same destination is the difference between the one-way
delay of the first packet and the one-way delay
of
the
second packet.
IPDV,,
=lOWD,
-OWDk\
The IPDV also called jitter is a very important metric for
real-time traffic. To provide a very good QoS for real-time
traffic, the jitter needs to be constant. We followed the
mentioned OWD and IPDV definitions for the rest of our
simulations.
S.
Andreozzi et al.
(131
provided an improved
DiffServ module for the
Ns-2
simulator that enabled OWD
and IPDV measurements. The work originated from work
by Femari et al. involving the study of delay measurement
in
queuing.
C.
DiJerentiated Services
DiffServ
is
a service standard that evolved from IntServ,
which tries to guarantee QoS on large networks. IntServ
handled traffic on a per-flow basis where as DiffServ treats
traffic in aggregation. The biggest advantage of DiffServ
is
that it is a more scalable architecture where
no
end-to-end
signalling
is
required.
It
makes use of the IPv4 header, which contains the DS
field
also
called the TOS octet. The byte is used
to
indicate
the need for precedence, delay, throughput and reliability.
Hereafter, packets are handled based on their DS fields.
The DiffServ architecture consists of a forwarding path
behaviour component and a background policy and
allocation component. The forwarding path behaviours
include the treatment of individual packets received as
implemented by the different queuing services. This can he
seen as
per-hop behaviour
(PHB) and
is
required to ensure
the differentiated treatment of the packets. The DiffServ
architecture aggregates traffic with similar
QoS
requirement
in
traffic classes that share the same PHB throughout the
network.
The complexity of the network
is
shifted to
its
edges,
which
in
turn reduces the network overhead by
laking
away
the need
of
signalling and per-flow state maintenance
in
the
network core.
Packets arriving at an edge router of a DiffSeN domain
will experience classification and traffic conditioning which
in turn restricts how aggregates are composed. The DiffServ
edge router performs conditioning and forwards the packets
using PHB. Each packet
is
marked with a codepoint, which
is identified with
a
particular aggregate. PHB is performed
along the route at each router until
an
inner router (core
router) is reached. The DiffServ edge router may have
extended services such as packet marking and traffic
shaping. The DiffServ core router is much simpler in design
and purpose. This node in theory has much
less
features
because
it
can be assumed that the traffic has already passed
through an edge router. The packets will have then been
marked and conditioned. The term
per-domain behaviour
(PDB)
is
used to describe the edge-to-edge behaviour
experienced by a DiffServ domain from traffic aggregate.
There are three types of PHBs in the DiffServ
Architecture:
Expedited Fowording
(EF) PHB,
Assured
Forwording
(AF) PHB and the default
Best-Effort
(BE)
PHB. These three forwarding treatments can be used to
build different services that can guarantee certain levels of
loss,
latency, jitter and bandwidth.
EF PHB's (as defined in
RFC
2598)
main purpose
is
to
provide a Virtual leased
lin
e"type of service, which
provides the building block to provide a service that
IEEE
AFRICON
2004
Packet
Sire
IByies)
325
128
...
2048
512
l"Cremen1
of
1?8
provides small packet
loss
ratio, low delay, low jitter and
assured bandwidth that, is very similar to RSVP that
provides Guaranteed Bandwidth Service. EF PHB focuses
on providing the necessary mechanisms for the forwarding
path,
to
ensure this kind of behaviour. EF PHB
is
ideal for
VolP and many other multimedia applications that require
low bandwidth, assured bandwidth, low delay and low jitter.
AF PHB (as defined in RFC 2597)
is
designed to ensure
that packets have
a
high delivery probability;
as
long
as the
forwarding
class
does not exceed the subscribed information
rate
-
otherwise the incoming traffic, which
is
out-of-profile,
will not be delivered with the same probability.
nis
may
also
include metrics such
as
levels of delay and jitter.
It
is
meant to support mainly business type traffic.
BE PHB (as defined in RFC 2474) provides us with a
Best Effort service. This PHB is needed to ensure that
no
traffic aggregate dies
of
starvation, which can be achieved
by implementing
a
mechanism in each node, such as
a
separate queue with
a
minimal predefined number
of
resources together with this PHB behaviour. This lower
class will
still
be able to travel the network even if the
sender does not know the network is DiffServ enabled.
More than one codepoint can be mapped to
a
certain PHB.
If an unrecognized
or
unspecified codepoint is encountered,
it can be mapped to
a
default PHB, which can for example
provide a
BE
service.
With the introduction of differentiated services, came the
Service
Level
Agreement
(SLA). This agreement is between
the client and the service provider and entails the classes of
traffic supported as well
as
the amount
of
traffic per class
allowed
[I],
[31.
Packets that enter from another domain may be remarked
according to the SLA between the two
domains.
Since
DiffServ does not require any end-to-end signalling, the
packets must be marked with
an
appropriate
Dif/eerentiuted
Services
Code
Point
(DSCP) value. The DSCP
in
the
DS
field of the IP header identifies the PHB that is to be
associated with
a
certain packet. This is used to specify
queuing, scheduling and drop precedence.
The main problem we are faced with is that
no
detailed
comparison studies exist
for
the schedulers
in
a
DiffServ
environment. There also exists very little literature
on
dealing with multi-class system from an analytical
perspective. With simulations we obtain various scheduler
performance measurements as well
as
how each of them
react to different traffic aggregations.
111.
SIMULATION
ENVIROMENT
Nerwork
Simuluror
(Ns-2) was used in Linux for the
various simulation scenarios. Ns-2 comes with its own
libraly of network topologies and traffic generators
along
with
a
network animator tool.
Ns-2
is
developed by
UCBiLBNL and by the VlNT project and is licensed
as
freeware. Ns-2 has DiffServ functionality, which we
extended by making
use
of
the DiffServ module
(131.
For our simulation, we used the topology depicted in
Figure
2.
It
consists
out
of
two edge routers and
a
core
router. This is
a
typica1 representation of the inner working
of
a
telecommunication service provider's network. This
topology would
also
aid us in generating
a
condition of
Load
80
?80
(Kbus)
1ncreme"I
of40
congestion by means of the bottleneck between the edge
routers. By having congestion, we are able to test the
schedulers in various network conditions, and seeing the
effect that different service rates has the
QoS,
especially the
delay metric.
80
280
Increment
of40
Figure
1:
Ns-2
Simulation Environment
Example
For this current simulation we only made
use
of CBR
traffic sources. The queue lengths are constant and are
defined at
30
packets for
EF
traffic and AFI, AF2 and BE at
50
packets.
IV.
EXPERIMENTAL
RESULTS
Our research involved two different scenarios. Scenario
1
involved the comparison and performance evaluation
of
the
various schedulers. Scenario
2
is
the analysis of various
aggregations of traffic to determine the influence of more
than
one
micro
flow
with different packet sizes and how the
different schedulers performed with it.
Table
1:
Scenario
1
Simnlslion
Parameters
Layout
2
Load
I
I
Mbpr
I
1
Mbps
.-
i
I
Layout1
I
..
,
.
,
,
.
El
Ttaflic
.I
.,
.
(Kbps)
I
I
Traffrrc
1
CBR CBR
The four different traffic classes are defined and used
in
the simulations. They compete for the same bandwidth over
our bottleneck link with bandwidth of 2Mbps (0.25MBps).
The following parameters
are
varied in the simulations: EF
Rate, BG Rate, EF Packet Size and the scheduler type.
Two-service rate definitions are used namely
EF
Rate and
BG
rate. EF Rate
is
the rate at which EF traffic enters the
edge
node whereas
BG
rate
is
the
combination
of
AF and
BE traffic dependent
on
the number of flows of each. There
are
6
AFI,
6
AF2 and
3
BE
flows configured. Their
aggregate rate is equal
to
the BG rate specified.
0-7083-8605-1
/$17.00
2004
IEEE
326
A.
Scenorio
I
The various schedulers were evaluated using the
parameters specified
in
Table
1.
Please note that the EF
traffic flow only consists of
a
single micro flow. The
average IPDV for real-time traffic remained fairly constant
for all packet sizes when using PQ. Not surprisingly, the
lower priority classes of PQ are starving.
It
is
important to
note that the IPDV increased exponentially for the BE
traffic as the packet size increased (Figure 3). The
remaining schedulers also perform admirably for all packet
sizes with a small increase
in
IPDV
for
larger packet sizes.
But since BE traffic
is
not delay sensitive, we merely
illustrated
this
to
enforce PQ's behaviour. Under conditions
of congestion, all the schedulers must give the high priority
traffic preference, thus they drop
in
the service that BE
traffic receives. WFQ
is
only effective for
BE
packet sizes
of
1024
bytes and smaller during BE traffic transmission.
LLQ
on
the other hand performs more
or
less the same with
its turning point at
1280
bytes.
=
Figure
3:
IPDV
-
BE
Traflir
(No
Congestion)
Figure
4:
IPDV
~
BE
Trafir
(Congestion)
In
Figure
5
and Figure
6
we illustrate how the
EF
traffic
is
affected under the same conditions. In the construction
of
the LLQ scheduler, the EF traffic
is
mainly handled by a
PQ,
thus the performance
is
the same for both PQ and LLQ.
It can be seen in the plots that WFQ delivers good
performance with little variation until it reach a packet size
of
1024
bytes. WFQ thus has the same effect of BE traffic
as
on
EF traffic.
The previous graphs give us detailed information about
how the schedulers perform for different packet sizes, but
only for a certain rate. Three dimensional plots are used, to
give us a visual model of how the different schedulers
IEEE
AFRICON
2004
0-7083-8605-1 /$17.00
2004
IEEE
perform for different rates and packet sizes. For real-time
traffic, the IPDV has the greatest influence on the QoS. This
means that IPDV
is
a critical parameter for time-sensitive
traffic. OWD very important
as
well, but if
it
stays constant
it
does not have a detrimental effect
on
the
QoS.
Figure
5:
IPDV
-
EF
Tralfie
(No
Congestion)
I
"
Figure
6
IPDV-EFTrdfir (Congestion)
Various 3D graphs were generated (from Figure
7
tn
Figure 12)
depicting
the
performance of the various
schedulers.
An
interesting result
of
the study
is
the influence
of the
BE
packet size on the EF traffic's IPDV. In the
results shown here, our EF Traffic rate is specified at
I
Mbps which takes up
50
percent of our line rate.
As
a quick illustration,
it
can be seen
in
graphs that the
BG packet size has a greater influence at a larger size, but
still the different schedulers react differently at certain rates.
Figure
7:
PQ IPDV
for
EF
Traflie
LLQ perform the best from all the schedulers with a
IEEE
AFRICON
2004
327
.,
1
s
linear increase in IPDV with the increase in BG packet size.
Having a look at the rest of the schedulers,
it
is noticeable
that SCFQ, SFQ, WFQ and WF'Qioutperform LLQ when
the BG packet size is equal
to
1280
bytes.
.
..
-~
Another conclusion that could he made is that of the fact
that the IPDV is
not
hugely influenced by the BG rate.
All
the schedulers seems more than adept in coping fast enough
for the specified rates, even if the total rate should exceed
the available bandwidth.
Using the
3D
plot is a step closer to perform constraint
delay profiling, since
it
reduces the amount of parameters
to
include. These
3D
plots
provide good insight can easily be
used with help in constructing a costing stmcture if the
topology is set up
to
reflect the real network. The graphs
could aid in selecting an appropriate scheduler
to
use.
Figure
12
LLQ
IPDV
lor
EF
TlaIlic
B.
Scenario2
This simulation scenario analyzes the effect of multiple
micro flows
on
the EF PHB. This includes how the OWD,
IPDV and servicing rates are influenced. Two cases exist
which we investigated. They were for
x
micro flows
with
the same packet size and
x
micro flows with variable packet
size.
The first was investigated by Jennings et al. who found
that increasing the number of micro flows for PQ,
left
the
IPDV unchanged for flows with equal packet size.
The main goal is
to
obtain the variation the aggregation
strategy causes
in
the QoS. We perform the same test to
obtain the variations of OWD and IPDV
on
the various
schedulers for different packet sizes for
a
variable number
of micro flows. The results were obtained for
2,
4
and
8
micro flows with a constant rate for the EF traffic. Scenario
1
contains the results for the single micro flow. In the
following figures we only depict
the
change difference
between
a
single flow and
two
flows with different packet
sizes. The packets sizes were
512
bytes and
768
bytes.
w-_um*EF.m
a'-
,I^I.Ya..,,,*-.I
0-7083-8605-1
/$17.00
2004
IEEE
328
IEEE
AFRICON
2004
The IPDV values certainly increased for all rates except
80
Kbps. Figure
13
clearly shows us that the aggregation
on
two
flows with different packet sizes does have
a
negative
impact on the IPDV, and thus
on
the QoS for EF traffic.
It
is
shown
in
more detail
in
Figure
14.
The IPDV does increase
more at certain
BG
packet size values, which
is
similar to
the scheduler’s behaviour
in
the previous scenario.
,cm
m”d
Er
,-
Figure
14
Difference
SCFQ
IPDV
far
hvo
micro
flows
V.
CONCLUSION
Various mechanisms and schedulers exist. As can be seen
thus far, there
is
a clear difference between the performance
of
the various schedulers and the impact of rate
on
them.
Some schedulers such
as
the legacy PQ, behaves
as
expected by starving the lower class traffic,
in
an
attempt to
guarantee
a
certain level of service to EF traffic.
As expected
LLQ
is
the best scheduler
on
our IPDV and
OWD tests. Schedulers’ performance varies for different
packets sizes and rates, thus choosing a specific scheduler
for a DiffServ router should also be dependant
on
the
average packet size you expect to receive.
The aggregation of various micro flows with different
packet sizes clearly illustrate that having multiple micro
flows with various packet sizes has
a
detrimental effect
on
the IPDV and
QoS.
VI.
FUTllREWORK
Currently we are busy performing an analytical analysis
on the results
in
an
effort to find
a
mathematical reference
for this behaviour.
Future work may include the analysis of how AF PHB
is
affected by various parameters including the effect of that
[4]
G. Almes,
S.
Kalidindi, M. Ekauskas,
”A
One-way
Delay Metric for IPPM, Intemet RFC
2679,
Advanced Network and Services, Sept. 1999.
G. Almes,
S.
Kalidindi, M. Ekauskas,
“A
Round-trip
Delay Metric for
IPPM”,
Internet RFC 2681,
Advanced Network and Services, Sept. 1999.
[6]
C. Demichelis,
P.
Chimento,
“IP
Packet Delay
Variation Metric for
IP
Performance Metrics (IPPM)”,
Internet RFC 3393, Network Working Group, Nov.
2002.
S.
Shenker, C. Patridge, R. Guerin, “Specification of
Guaranteed Quality of Service”, RFC 2212, Sept.
1997.
(81 Richard Schaphorst, “Videoconferencing and
Videotelephony -Technology and Standards”,
2
nd
Edition, Artech House, 1999.
W. Jiang,
H.
Schulzrinne,
“Modelling
Of
Pocket
Loss
and Delay and Their Eflecr
on
Real-Time Multimedia
Service Quality”,
In Proceedings loth International
Workshop Network and Operations System Support
for Digital Audio and Video, June 2000.
[IO]
G.
brig,
H.T. Mouftah,
“End-to-End
QoS
Guarantees Over Diffserv Networks”,
In Proceedings
6’h
IEEE Symposium on Computer
and
Communications, July 2001.
[Ill C. Simon, A. Vidacs,
“End-to-End Relotive
Diferentioted Services
for
IP Networks”,
In
Proceedings
IEEE
Symposium on Computers and
Communications, July 2002.
“Performance Evaluation
of
Per-Hop Forwarding Behaviours in
the
Dijjjeen,
Internet”,
In
Proceedings
5“
IEEE
Symposium on
Computers and Communications, July 2000.
[I31
S.
Andreozzi,
“Dflerentiared Services:
an
Experimental
vs.
Simulated Case
Study”,
In
Proceedings
7*
IEEE Symposium
on
Computers and
Communications, July 2002.
[14]
T. Ferrari,
“Measurement Based Analysis ofDelqv
in
Priority Queuing”,
Proceeding of IEEE Global
Telecommunication Conference Globecom
2001,
Texas, Nov
2001.
[15]
R. Majoor,
“Quoliy
of
Service in the Internet Age”,
SATNAC Conference Proceedings, 2003.
[I61 ”The Network Simulator
-
Ns-2”, [Web]
http://www.isu.edulnsnadns
[Accessed
20
lune
20031
[5]
[7]
[9]
[I21 Z Di, H.T. Mouftah,
EF
PHB
on
a
network that does not have bandwidth
in
abundance.
Johan
Smil,
B.lng
(Elcctec
&
Electronic
Engineering)
’02,
B.Sc
(Information
Tcchnoiom),
is
cum01Iy
an
M.lna
..
.
sNdent
a1
the
Rand
Afnkaans
University,
lohannnburg,
South
Africa.
He
is
currntly
pan
of
the
Telecommunication
Research
Group in
the
Cybemctics department
headed
by
REFERENCES
[I]
XXo,
L.
M. Ni, “Inter net QoS: the Big Picture”,
Prof.
H.C.F. Fmeira.
[2]
IEEE Network Magazine, March 1999.
B.
Braden,
D.
Clark,
S.
Shenker, “Internet Protocol
DARPA Intemet Program Specification”, Internet
RFC 791, Information Sciences Institute, Sept. 1981.
S.
Blake,
D.
Black, M. Carlson, “An Architecture for
Differentiated Services”, Intemet RFC
2475,
Network
Working Group, Dec. 1998.
[3]
0-7083-8605-1
/
$17.00
2004
IEEE
