Transcript Quality of Service (QoS)

Chapter 30
Quality of
Service
Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
Chapter 30: QoS
30.1 DATA-FLOW CHARACTERISTICS
Applications Sensitivity to reliability, delay,
jitter, and bandwidth.
30.2 FLOW CONTROL TO IMPLEMENT QoS
oTraffic Shaping/Policing: leaky/token bucket
oScheduling (traffic shaping):
FIFO, priority , and weighted fair queuing
oResource reservation and admission control
.
oThere are two major models to enhance QoS:
1) Integrated Services
2) Differentiated Services
30.3 INTEGRATED SERVICES (IntServ)
o Bandwidth (and other resources) is explicitly reserved based
on type of data-flow.
oService Classes:
 Quantitative– Guaranteed, an application
specifies the amount of delay and data rate.
 Qualitative – Controlled-Load, tolerate some
delay but sensitive to overloaded networks and
packet loss; as Email, FTP, HTTP applications
requesting the possibility of no or low loss.
oResource Reservation (RSVP) for connection-oriented protocol:
Reserve in advance the requested resources by a data flow.
30.3
30.4 DIFFERENTIATED SERVICES (DiffServ)
oDifferentiated Services:
Priorities Applications classes.
oTraffic Conditioners:
Used to implement DiffServ.
30.4
30-1 DATA FLOW CHARACTERISTICS
oTo provide Internet applications QoS we
first need to define what we need for each
application.
oTraditionally, four types of characteristics
are attributed to a flow:
reliability, delay, jitter, and bandwidth.
o Define them, then investigate for each
application type its requirements.
30.5
30.1 Definitions
Informal definitions of the four characteristics:
Reliability is a characteristic that a flow needs in order to
deliver the packets safe and sound to the destination.
Delay Source-to-destination packet delivery duration
time.
Jitter is the variation in delay for packets belonging to
the same flow.
Bandwidths : Different applications need different b/s
channel capacity & duration availability.
30.6
30.30.2
Sensitivity of Applications
Now let us see how various applications are
sensitive to some flow characteristics. Table 30.1
gives a summary of application types and their
sensitivity.
30.7
Table 30.1: Sensitivity of applications to flow characteristics
30.8
30.30.3 Flow Classes
Based on the flow characteristics, we can
classify flows into groups, with each group
having the required level of each characteristic.
The Internet community has not yet defined
such a classification formally.
However, we know, for example, that a
protocol like FTP needs a high level of reliability
and probably a medium level of bandwidth, but
the level of delay and jitter is not important for
this protocol.
30.9
30-2 FLOW CONTROL TO IMPROVE QoS
Although Internet does not define
formal classes of flow, an IPv4
datagram has a Type of Service
(ToS) field (Priority field in IPv6)
that define the required service
for a set of application’s
datagrams.
30.10
30.2.1 Scheduling
It is mostly at a router that a packet
may be delayed, suffer from jitters, be
lost, or be assigned the required BW.
Hence, at routers several scheduling
techniques are designed to improve
QoS: FIFO, priority, and weighted fair
queuing.
30.11
Figure 30.1 : FIFO queue
30.12
Figure 30.2 : Priority queuing
Q1
*
*
*
Qn
30.13
Figure 30.3 : Weighted fair queuing
30.14
30.2.2 Traffic Shaping or Policing
 To control the amount and the rate of traffic.
Traffic Shaping is to control the traffic when it
leaves the network.
Traffic Policing is to control the traffic when it
enters the network.
Two techniques can shape or police the traffic:
leaky bucket and token bucket.
30.15
Bursty Traffic Policing VS. Shaping:
(http://www.cisco.com/c/en/us/support/docs/quality-ofservice-qos/qos-policing/19645-policevsshape.html#traffic)
The following diagram illustrates the key difference.
Traffic Policing propagates bursts. When the traffic rate reaches the
configured maximum rate, excess traffic is dropped (or remarked).
The result is an output rate that appears as a saw-tooth with crests
and troughs.
Traffic Shaping In contrast to policing, retains excess packets in a
QUEUE and then schedules the excess for later transmission over
increments of time. The result of traffic shaping is a smoothed
packet output rate.
Shaping implies the existence of a queue and of sufficient memory to
buffer delayed packets, while policing does not buffer excess packets.
30.16
Bursty Traffic Policing VS. Shaping:
(http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html#traffic)
30.17
Leaky Bucket
A water bucket leaks (outputs) in a constant rate
of water regardless of the input flow of water.
Hence, a network can regulate the output data
rate of its bursty input traffic rate.
30.18
Figure 30.4: Leaky bucket
2 Mbps
7
30.19
8
9 10
Figure 30.5: Leaky bucket implementation
Algorithm byte-counting LB for variable size
packets
1: count = n; (at the clock tick)
While ((count => packet-size) & (Queue is not empty))
{send packet;
count = count - packet-size}
go to 1;
30.20
Figure 30.6 :
Token Bucket
Since the Leaky Bucket is not fair for idle host for long times then gets
bursty data, it still transmits the average rate (ignoring its long idle
time)! Hence, we have Token Bucket (TB).
30.21
(http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfpolsh.html#wpxref22120)
The bucket gets tokens at a certain rate (data unit per sec, du/s).
A token is permission for the source to send a certain number of
du’s into the network.
To send a packet, remove from the bucket a number of tokens
equal in representation to the packet size in du’s.
If not enough tokens are in the bucket to send a packet, the
packet either:
o queued waiting until the bucket has enough tokens
(in the case of a shaper), OR
o discard/marked-down (in the case of a policer).
If the bucket fills to its specified capacity (max burst size) , newly
arriving tokens are discarded.
A token bucket permits burstiness, but bounds (shape/police) it.
30.22
The token bucket algorithm provides users with
three actions/categories for each in-bound
(incoming) packet, in case of Traffic Policing
configured :
o a conform action– Config. to transmit packet,
o an exceed action– Config. to transmit packet but
with lower priority, and
o an optional violate – Drop the packet.
30.23
Example 30.2
Let assume that the bucket capacity is 10,000 tokens and
tokens are added at the rate of 1000 tokens per second. If the
system is idle for 10 seconds (or more), the bucket collects
10,000 tokens and becomes full. Any additional tokens will
be discarded. The maximum average rate is shown below.
30.24
30.2.3 Resource Reservation
A flow of data needs resources such as a buffer,
bandwidth, CPU time, and so on. The quality of
service is improved if these resources are reserved
beforehand. Below, we discuss a QoS model called
Integrated Services, which depends heavily on
resource reservation to improve the quality of
service.
30.25
30.2.4 Admission Control
Admission control refers to the mechanism used
by a router or a switch to accept or reject a flow
based on predefined parameters. Before a router
accepts a flow for processing, it checks the flow
specifications to see if its capacity can handle the
new flow. It takes into account bandwidth, buffer
size, CPU speed, etc., as well as its previous
commitments to other flows. Admission control in
ATM networks is known as Connection Admission
Control (CAC), which is a major part of the
strategy for controlling congestion..
30.26
30-3 INTEGRATED SERVICES (INTSERV)
IETF developed the Integrated Services
(IntServ) model. In this model, which is a flowbased architecture, resources such as
bandwidth are explicitly reserved for a given
data flow. In other words, the model is
considered a specific requirement of an
application in one particular case regardless of
the application type.
30.27
30.3.1 Flow Specification
We said that IntServ is flow-based. To define a
specific flow, a source needs to define a flow
specification, which is made of two parts:
30. Rspec (resource specification). Rspec defines
the resource that the flow needs to reserve (buffer,
bandwidth, etc.).
2. Tspec (traffic specification). Tspec defines the
traffic characterization of the flow, which we
discussed before.
30.28
30.3.2 Admission
After a router receives the flow specification from
an application, it decides to admit or deny the
service. The decision is based on the previous
commitments of the router and the current
availability of the resource.
30.29
30.3.3 Service Classes
Two classes of services have been defined for
Integrated Services: guaranteed service and
controlled-load service.
30.30
30.3.4 RSVP
Since IP is a connectionless protocol, a new
protocol is designed to run on top of IP to make it
connection-oriented.
A
connection-oriented
protocol needs to have connection establishment
and connection termination phases, as we
discussed in Chapter 18. Before discussing RSVP,
we need to mention that it is an independent
protocol separate from the Integrated Services
model. It may be used in other models in the
future.
30.31
Figure 30.7 : Path messages
30.32
Figure 30.8 : Resv messages
30.33
Figure 30.9 : Reservation merging
30.34
30.3.5 Problems with Integrated Services
There are at least two problems with Integrated
Services that may prevent its full implementation
in the Internet: scalability and service-type
limitation: scalability and service-type limitation.
30.35
30-3 DIFFERENTIATED SERVICES (DIFFSERV)
In this model, packets are marked by
applications into classes according to their
priorities. Routers and switches, using various
queuing strategies, route the packets. This
model was introduced by the IETF to handle
the shortcomings of Integrated Services.
30.36
30.4.1 DS Field
In DiffServ, each packet contains a field called the
DS field. The value of this field is set at the
boundary of the network by the host or the first
router designated as the boundary router. IETF
proposes to replace the existing ToS (type of
service) field in IPv4 or the priority class field in
IPv6 with the DS field, as shown in Figure 30.10.
30.37
Figure 30.10 : DS field
30.38
30.4.2 Per-Hop Behavior
The DiffServ model defines per-hop behaviors
(PHBs) for each node that receives a packet. So
far three PHBs are defined: DE PHB, EF PHB,
and AF PHB.
30.39
Figure 30.11: Traffic conditioner
30.40