Overview
TDDD36
Secure Mobile Systems
Resource allocation in computer
systems and networks:
Systems Software
Lecture 6: Admission control & QoS
Simin Nadjm-Tehrani
Real-time Systems Laboratory
Department of Computer and Information Science
Linköping University
Project Course TDDD36
System Software module
29 pages
Autumn 2012
• Need to allocate available resources
– To some applications/tasks/messages
– If there is overload - which ones?
• How is allocation applied to a flow of
messages?
• Need to dynamically adapt as load mix
and resource dynamics changes
Project Course TDDD36
System software module
This lecture
• Scheduling on one CPU (short overview)
• From single CPU to networks
– Some basic notions: QoS parameters,
requirements/provision
• Q
Quality
li off service
i in
i networked
k d (wired)
( i d)
applications
– QoS mechanisms
– Intserv, Diffserv
Project Course TDDD36
System software module
3 of 29
Autumn 2012
From lecture 1
• Tacks (processes) running on one CPU
• What are the shared resources?
– CPU
– Memory
y
– I/O channels
– ...
• What happens if the set of tasks that
are ready to execute grows?
Project Course TDDD36
System software module
CPU scheduling
• Scheduler decides which process from
the ready queue to run next
• First-in-First-out
– Non-preemptive, inefficient use of resources
• Shortest job first
– Uses estimate of a process’s next CPU burst
• Priority-based scheduling
– May be combined with increased priority
when aging
2 of 29
Autumn 2012
4 of 29
Autumn 2012
Network resources
• Application nodes (edge nodes)
– CPU
– Power
– Memory
y (buffer
(
space)
p
)
• Links
– Bandwidth
• Forwarding nodes: buffer space
• Round robin: allocates fixed quantum
Project Course TDDD36
System software module
5 of 29
Autumn 2012
Project Course TDDD36
System software module
6 of 29
Autumn 2012
1
Network quality of service
Example applications
• Elastic or inelastic
• Application level requirements
– Mail or video conference
– Image quality (resolution/sharpness),
viewing size, voice quality
• Interactive or non-interactive
– Voice communication or file transfer
• Tolerant or non-tolerant
• Enforcement
E f
l
level
l iindicators
di
– MPEG video-on-demand or automated
control
– Throughput, delay, jitter, loss ratio,
reliability (lack of erroneous messages and
duplications)
• Adaptive or non-adaptive
– Audio/video streaming or electronic trading
• Real-time or non-real-time
– IP-telephony or A/V on demand (streaming)
Project Course TDDD36
System software module
7 of 29
Autumn 2012
Project Course TDDD36
System software module
QoS guarantees
8 of 29
Autumn 2012
Leaky bucket
• Arrival profile can be described in terms of a pair (r, b)
where r is the average bit rate, and b is an indication of
burst size.
• Need description of required/provided
service
– Service commitment: % of dropped packets,
average end-to-end delay
– Traffic profile: definition of the flow entitled
to the service, arrival rates, burstiness,
packet size,…
Project Course TDDD36
System software module
9 of 29
Autumn 2012
Project Course TDDD36
System software module
Philosophies
• Service differentiation
– Some basic notions: QoS parameters,
requirements/provision
to drop?
• Q
Quality
li off service
i in
i networked
k d
applications
– QoS mechanisms
– Intserv, Diffserv
• Example from 3G load control taken
from a Master thesis project
– All should get something
• Orthogonal: Adaptation
– Adaptive ones should adapt to make room
for non-adaptive ones
Project Course TDDD36
System software module
This lecture
• Scheduling on one CPU (short overview)
• From single CPU to networks
– When there are overloads some
connections/packets/applications are
preferred to others
Which one
• Fairness
10 of 29
Autumn 2012
11 of 29
Autumn 2012
Project Course TDDD36
System software module
12 of 29
Autumn 2012
2
QoS mechanisms: node level
• Admission control
– To manage the limited resources in presence
of oversubscriptions
– Examples:
Leaky bucket
• Arrival profile can be described in terms of a pair (r, b)
where r is the average bit rate, and b is an indication of
burst size.
• Policing (does the application ask for the same
l
level
l off resources that
th t was given
i
as a ttraffic
ffi
profile?)
• Shaping (influencing the flow of packets fed into
the network to adapt to agreed resource picture)
• Scheduling
• Buffer management
Traffic shaping...
Project Course TDDD36
System software module
13 of 29
Autumn 2012
Project Course TDDD36
System software module
Scheduling
• Which packet should be forwarded at
the network layer (to serve which QoS
parameters)?
• No QoS: FIFO
• Fixed priority scheduling
WFQ rough description
• Instead of allocating to all packets from
one flow at a time, imagine an
approximation to an ideally fair
scheduler: one packet from each flow in
a given time interval
• Allocate the outgoing bandwidth
according to a weight for each flow
• For flows that are described as a leaky
bucket, the max delay per packet is
computable
– With no guarantees on per packet delay,
some can starve
• Weighted Fair Queuing (WFQ)
• Class based queuing
Project Course TDDD36
System software module
15 of 29
Autumn 2012
Project Course TDDD36
System software module
Class-based link sharing
• Hierarchical allocation of the bandwidth
according to traffic classes
• Each class allocated a max share under
a given interval, and the excess shared
according
di
tto some sharing
h i
policy
li
Link
User type A
User type B
40%
60%
Real-time
30%
Project Course TDDD36
System software module
ftp
… 5%
…
News
…
…
16 of 29
Autumn 2012
Buffer management
• Scheduling works as long as buffers are
infinite
– In reality buffers (queues) get full during
overloads
– Shall we drop all the packets arriving after
the overload starts?
• Buffer management is about
determining which stored packets to
drop in preference to incoming ones
Usenet
…
14 of 29
Autumn 2012
– Can adopt differentiated drop policies
Real-time
17 of 29
Autumn 2012
Project Course TDDD36
System software module
18 of 29
Autumn 2012
3
This lecture
• Scheduling on one CPU (short overview)
• From single CPU to networks
– Some basic notions: QoS parameters,
requirements/provision
• Q
Quality
li off service
i in
i networked
k d (wired)
( i d)
applications
– QoS mechanisms
– Intserv, Diffserv
• Example from 3G load control taken
from a Master thesis project
Project Course TDDD36
System software module
QoS: Across network nodes
• IP datagrams delivered with best effort
• IntServ was defined to deliver IP
packets with differentiated treatment
across multiple routers (1994)
• Introduced 3 service classes:
– Best effort
– CL: Controlled Load (acceptable service
when no overload)
– GS: Guaranteed Service (strict bounds on eto-e delay)
19 of 29
Autumn 2012
Project Course TDDD36
System software module
IntServ
20 of 29
Autumn 2012
Sending Tspec & receiving Rspec
Destination
• Each router keeps a soft state for each
flow (a session) currently passing
through it
– GS: the leaky-bucket-based requirements
from a flow induce a max local delay in each
router
• The soft state created with a reservation
scheme RSVP, and refreshed while the
session is in progress
PATH
RESV
Source
RSVP routers
Project Course TDDD36
System software module
21 of 29
Autumn 2012
Project Course TDDD36
System software module
QoS specifications
• T-spec (traffic specification)
Not deployed successfully!
• IntServ has met resistance for several
reasons, including:
– A token bucket specification
•
•
•
•
•
22 of 29
Autumn 2012
token rate - r
bucket size - b
peak rate - p
maximum packet size - M
minimum policed unit - m
– Dynamic and major changes in reservation
– Not all routers RSVP enabled
– Set
S t up time
ti
can be
b proportionately
ti
t l long
l
compared to session time
– Interactive sessions need to set up at each
end
• R-spec (reservation specification)
– Service Rate – R
• The bandwidth requirement
– Slack Term – S
• The delay requirement
Project Course TDDD36
System software module
23 of 29
Autumn 2012
Project Course TDDD36
System software module
24 of 29
Autumn 2012
4
DiffServ (1998)
• Based on resource provisioning (for a
given SLA) as opposed to reservation
• Applied to traffic aggregates as opposed
to single flows
• Forwarding treatment as opposed to
e-to-e guarantees
• Edge routers label packets/flows upon
forwarding to next domain, and accept
only in-profile packets when accepting
from other domains
Project Course TDDD36
System software module
25 of 29
Autumn 2012
Service classes
• Marked with two bits:
– (P) Premium class: intended for
preferential treatment to which
policing is applied with a small bucket
size
– (A) Assured class: pass through
policing with a bucket size equal to
the given burst
– Packets with A-bit compete with best
effort packets when buffers get full
Project Course TDDD36
System software module
Scalability of DiffServ
• Admission control is now at edge nodes
not every path on a route
• No set-up time and per-flow state in
each router
• At the cost of No e2e guarantees
Project Course TDDD36
System software module
27 of 29
Autumn 2012
26 of 29
Autumn 2012
Overview
Resource allocation in computer
systems and networks:
• Need to allocate available resources
– To some applications/tasks/messages
– If there is overload - which ones?
• How is allocation applied to a flow?
• Need to dynamically adapt as load mix
and resource dynamics changes
Project Course TDDD36
System software module
28 of 29
Autumn 2012
Example: Master thesis
Thomas Lingvall, 2002
– Best Masters thesis Prize in the Realtime Systems in Sweden
– Accepted for publication (MSWIM 02)
Load control of a 3G radio network
controller during overloads
Now it is time to look
at LTE (4G) and
hybrid solutions
Project Course TDDD36
System software module
29 of 29
Autumn 2012
5