TDDD82 Secure Mobile Systems
Lecture 6: Quality of Service
Mikael Asplund
Real-time Systems Laboratory
Department of Computer and Information Science
Linköping University
Based on slides by Simin Nadjm-Tehrani
Overview
Resource allocation problem:
●
Allocate available resources
–
–
●
To some applications/tasks/messages
If there is overload - which ones?
Load mix and resources can change
dynamically
This lecture
●
●
Scheduling on one CPU (short overview)
From single CPU to networks
–
●
Some basic notions: QoS parameters,
requirements/provision
Quality of service in networked (wired)
applications
–
–
QoS mechanisms
Intserv, Diffserv
From lecture 1
●
●
Tacks (processes) running on one CPU
What are the shared resources?
–
–
–
–
●
CPU
Memory
I/O channels
...
What happens if the set of tasks that are
ready to execute grows?
CPU scheduling
●
●
Scheduler decides which process from the ready
queue to run next
First-in-First-out
–
●
Shortest job first
–
●
Uses estimate of a process’s next CPU burst
Priority-based scheduling
–
●
Non-preemptive, inefficient use of resources
May be combined with increased priority when aging
Round robin: allocates fixed quantum
Quality of Service
●
Not Best effort
●
Provide guarantee!
●
Requires:
–
–
–
Model of source
Model of resource
Model of provider
QoS Philosophies
●
Service differentiation
–
●
Fairness
–
●
When there are overloads some
connections/packets/applications are preferred to others
All should get something (but how much?)
Orthogonal: Adaptation
–
Adaptive ones should adapt to make room for non-adaptive ones
Networked applications
●
Edge nodes
–
–
–
●
Links
–
●
CPU
Power
Memory (buffer space)
Bandwidth
Forwarding nodes: buffer space
QoS guarantees
●
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,…
Recall lecture 5
●
Fault-tolerance requires replication
●
Consistent replication requires agreement
●
Agreement requires timeliness guarantees
Network quality of service (QoS)
●
Application level requirements
–
●
Image quality (resolution/sharpness), viewing size,
voice quality
Enforcement level indicators
–
Throughput, delay, jitter, loss ratio, reliability (lack of
erroneous messages and duplications)
Application types
●
Elastic or inelastic
–
●
Interactive or non-interactive
–
●
MPEG video-on-demand or automated control
Adaptive or non-adaptive
–
●
Voice communication or file transfer
Tolerant or non-tolerant
–
●
Mail or video conference
Audio/video streaming or electronic trading
Real-time or non-real-time
–
IP-telephony or A/V on demand (streaming)
QoS mechanisms: node level
●
Admission control
–
–
To manage the limited resources in presence of
oversubscriptions
Examples:
●
●
●
●
Policing (does the application ask for the same level of
resources that was given as a traffic profile?)
Shaping (influencing the flow of packets fed into the network
to adapt to agreed resource picture)
Scheduling
Buffer management
Leaky bucket
●
Smooth traffic flows
●
Hard upper limit on rate
●
Inefficient use of network
resources
Token Bucket
●
●
●
●
Token Bucket mechanism, provides a means for limiting input to
specified Burst Size and Average Rate.
Bucket can hold b tokens;
tokens are generated at a rate of r token/sec
– unless bucket is full of tokens.
Over an interval of length t, the size of all admitted packets is less
than or equal to (r t + b).
Token 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.
Scheduling
●
●
●
●
●
Which packet should be forwarded at the
network layer (to serve which QoS
parameters)?
No QoS: FIFO
Fixed priority scheduling
Weighted Fair Queuing (WFQ)
Class based queuing
Scheduling
●
FIFO scheduling
–
●
No QoS possible
Priority scheduling
–
–
–
–
One queue for each priority
Guaranteed service for high priority flows
Risk for starvation!
What is the delay for a packet with priority i?
Generalized Processor Sharing
●
●
●
Work conserving (router not
idle when there is work to do)
Guarantees proportional
fairness (i.e., no starvation)
1
2
Works as follows:
–
Assign a logical queue for each flow
–
Serve an infinitesimal amount from
each queue
3
GPS approximations
●
Round robin (RR): serve a packet from each
queue in a round robin fashion
–
–
●
Ensures basic fairness
Fails if the packets are not of the same size
Weighted RR: serve n packets according to the
weight of the queue in a RR fashion
–
–
Queues with small packets get more weight to get a fair share
The packets in a flow should be of the same size
Weighter Fair Queueing (WFQ)
●
●
Approximates GPS
Idea: serve packets according to finish order of
GPS
–
●
●
Not possible, while being work conservative (requires
clairvoyance)
Close enough: serve packets according to
finish order of GPS as known at any given time
Also used in CPU scheduling: default scheduler
in Linux kernel ”Completely Fair Scheduler”
WFQ bounds
●
If flows follow leaky bucket (r,b) then the maximum delay experienced
by a packet in burst b_i:
R: Service rate
wi: weight of flow i
●
For K hops:
Lmax : maximum packet size, Cj output link rate for node j
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 to some sharing
policy
Link
User type A
User type B
40%
60%
Real-time
30%
Usenet
…
ftp
… 5%
…
News
…
…
Real-time
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
–
Can adopt differentiated drop policies
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 e-to-e delay)
IntServ
●
Each router keeps a soft state for each flow
(a session) currently passing through it
–
●
GS: the token-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
QoS specifications in Intserv
●
T-spec (traffic specification)
–
A token bucket specification
●
●
●
●
●
●
token rate - r
bucket size - b
peak rate - p
maximum packet size - M
minimum policed unit - m
R-spec (reservation specification)
–
Service Rate – R
●
–
The bandwidth requirement
Slack Term – S
●
The delay requirement
Sending Tspec & receiving Rspec
PATH
Destination
RESV
Source
RSVP routers
Difficult to deploy in large scale
●
IntServ has met resistance for several
reasons, including:
–
–
–
–
Dynamic and major changes in reservation
Not all routers RSVP enabled
Set up time can be proportionately long compared to
session time
Interactive sessions need to set up at each end
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
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
Two-bit diffserv edge router
A set
Token
available?
No
Clear A bit
Token
Packet
Marked?
Not marked
Forwarding
engine
P set
Token
Token
available?
No
Drop packet
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 end-to-end guarantees
Hint
●
●
●
Master thesis of IT student Jens Green:
”A set of proof-of-concept changes to the Spotify
Android application that implements simple
traffic shaping techniques, reducing selected
application features’ energy consumption over
3G networks by 22-54% during music playback.”
Planerad framläggning 23/2