TDDD82 Secure Mobile Systems Lecture 6: Quality of Service Mikael - - PowerPoint PPT Presentation

TDDD82 Secure Mobile Systems Lecture 6: Quality of Service

Mikael Asplund Real-tjme Systems Laboratory Department of Computer and Informatjon Science Linköping University

Based on slides by Simin Nadjm-Tehrani

Reading

• Silberschatz et al. 9th and 10th editions

– Chapter 5.1-5.5, 5.8

• El-Gendy et al. 2003

Overview

Resource allocatjon problem:

• Allocate available resources

– To some applicatjons/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 notjons: QoS parameters,

requirements/provision

• Quality of service in networked (wired)

applicatjons

– QoS mechanisms – Intserv, Difgserv

From previous lectures

• Tasks (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

Non-preemptive vs preemptive

Static vs dynamic scheduling

• Static (off-line)

– complete a priori knowledge of the task set and its constraints is available – hard/safety-critical system

• Dynamic (on-line)

– partial taskset knowledge, runtime predictions – firm/soft/best-effort systems, hybrid systems

CPU Scheduler

Burstiness

Burst histogram

Which job should run?

Burst time Interactive Waited 1 5ms Y 1ms 2 10ms N 20ms 3 2ms N 10ms 4 15ms Y 15ms 5 10ms N 40ms

What is a good scheduler?

Scheduling Criteria

• Throughput –

# of processes that complete their execution per time unit

• Energy consumption – Mobile phones, cloud computing, ...
• Turnaround time –

amount of time to execute a particular process

• Waiting time –

amount of time a process has been waiting in the ready queue

• Response time –

amount of time it takes from when a request was submitted until the first response is produced, not including output (for time-sharing environment)

• Deadlines met? – in real-time systems

First-Come, First-Served (FCFS) Scheduling

Process Burst Time P1 24 P2 3 P3

3

• Suppose that the processes arrive in the order: P1 , P2 , P3
• The Gantt Chart for the schedule is:

P1 P2 P3 24 27 30

FCFS Performance

P1 P2 P3 24 27 30

Waiting time Pi = start time Pi – time of arrival for Pi

FCFS Performance

• Waiting time for P1 = 0; P2 = 24; P3 = 27
• Average waiting time: (0 + 24 + 27) / 3 = 17
• Average turnaround time: (24 + 27 + 30) / 3= 27

P1 P2 P3 24 27 30

Waiting time Pi = start time Pi – time of arrival for Pi

FCFS normally used for non-preemptive batch scheduling, e.g. printer queues (i.e., burst time = job size)

Can we do better?

Yes!

Suppose that the processes arrive in the order P2 , P3 , P1

• The Gantt chart for the schedule is:
• Waiting time for P1 = 6; P2 = 0, P3 = 3
• Average waiting time: (6 + 0 + 3)/3 = 3 - much better!
• Average turnaround time: (3 + 6 + 30) / 3) = 13

P1 P3 P2 6 3 30

Convoy effect

• Short process behind long process
• Idea: shortest job first?

Shortest-Job-First (SJF) Scheduling

• Associate with each process the length of its next

CPU burst.

• Use these lengths to schedule the shortest ready

process

• SJF is optimal

– gives minimum average waiting time for a given set of

processes

Two variants of SJF

• nonpreemptive SJF – once CPU given to the

process, it cannot be preempted until it completes its CPU burst

• preemptive SJF – preempt if a new process

arrives with CPU burst length less than remaining time of current executing process.

– Also known as Shortest-Remaining-Time-First (SRTF)

Process Arrival Time Burst Time P1 0.0 7 P2 2.0 4 P3 4.0 1 P4 5.0 4

• with non-preemptive SJF:
• Average waiting time = (0 + 6 + 3 + 7) / 4 = 4
• Average turnaround time = (7 + 10 + 4 + 11) /4 = 8

Example of Non-Preemptive SJF

P1 P3 P2 7 3 16 P4 8 12

Example of Preemptive SJF

Process Arrival Time Burst Time P1 0.0 7 P2 2.0 4 P3 4.0 1 P4 5.0 4

• with preemptive SJF:
• Average waiting time = (9 + 1 + 0 +2) / 4 = 3
• Average turnaround time = (16 + 5 + 1 + 6) /4 = 7

P1 P3 P2 4 2 11 P4 5 7 P2 P1 16

Predicting Length of Next Burst

• Need to estimate!
• Based on length of previous CPU bursts,

using exponential averaging:

• 1. tn=actual length of nth CPU burst
• 2. τn+1= predicted value for the next CPU burst
• 3. α , 0≤α≤1

4 . Define:

τ n+1=α t n+(1−α ) τn.

+

+

SJF is a special case of priority scheduling

Priority Scheduling

• A priority value (integer) is associated with each process
• The CPU is allocated to the process with the highest

priority (often smallest integer  highest priority)

– preemptive – nonpreemptive

• Allows giving high priority to important jobs

– What are important jobs?

Challenge for Priority Scheduling

• Problems:

– Starvation – low-priority processes may never execute – Long jobs, even if delayed will monopolize the CPU

• Solution:

– Aging – as time progresses increase the priority of the

process

• How to balance age and priority?

What if we make aging the main scheduling factor?

Round Robin (RR)

• Each process gets a small unit of CPU time:

– time quantum, usually 10-100 milliseconds.

• After this time has elapsed, the process is

preempted and added to the end of the ready queue.

Round Robin performance

• Assume n processes in the ready queue and

time quantum q

• Each process gets 1/n of the CPU time in

chunks of at most q time units at once.

• No process waits more than (n-1)q time units.

Example: RR with Time Quantum q = 20

Process Burst Time P1 53 P2

17

P3 68 P4

24

• The Gantt chart is:
• Typically, higher average turnaround than SJF, but better response

P1 P2 P3 P4 P1 P3 P4 P1 P3 P3 20 37 57 77 97 117 121 134 154 162

Choice of time quantum (q)

• q very large  FCFS
• q very small  many context switches
• q must be large w.r.t. context switch time,
• therwise too high overhead

How is turnaround time affected by the choice of time quantum?

• Option A:

– Increased Q → increased turnaround time

• Option B:

– Increased Q → decreased turnaround time

• Option C:

– No general rule

RR: Turnaround Time Varies With Time Quantum

Problems with RR and Priority Schedulers

• Priority based scheduling may cause starvation

for some processes.

• Round robin based schedulers are maybe too ”fair”...

we sometimes want to prioritize some processes.

• Solution: Soon, first lets talk about QoS in

networking

Quality of Service

• Not Best efgort
• Provide guarantee!
• Requires:

– Model of source – Model of resource – Model of provider

Recall lecture 5

• Fault-tolerance requires replicatjon
• Consistent replicatjon requires agreement
• Agreement requires tjmeliness guarantees

QoS Philosophies

• Service difgerentjatjon

– When there are overloads some

connectjons/packets/applicatjons are preferred to others

• Fairness

– All should get something (but how much?)

• Orthogonal: Adaptatjon

– Adaptjve ones should adapt to make room for non-adaptjve ones

Networked applicatjons

• Edge nodes

– CPU – Power – Memory (bufger space)

• Links

– Bandwidth

• Forwarding nodes: bufger space

QoS guarantees

• Need descriptjon of required/provided

service

– Service commitment: % of dropped packets, average

end-to-end delay

– Traffjc profjle: defjnitjon of the fmow entjtled to the

service, arrival rates, burstjness, packet size,…

Network quality of service (QoS)

• Applicatjon level requirements

– Image quality (resolutjon/sharpness), viewing size,

voice quality

• Enforcement level indicators

– Throughput, delay, jituer, loss ratjo, reliability (lack of

erroneous messages and duplicatjons)

Applicatjon types

• Elastjc or inelastjc

– Mail or video conference

• Interactjve or non-interactjve

– Voice communicatjon or fjle transfer

• Tolerant or non-tolerant

– MPEG video-on-demand or automated control

• Adaptjve or non-adaptjve

– Audio/video streaming or electronic trading

• Real-tjme or non-real-tjme

– IP-telephony or A/V on demand (streaming)

QoS mechanisms: node level

• Admission control

– To manage the limited resources in presence of

• versubscriptjons

– Examples:

• Policing (does the applicatjon ask for the same level of

resources that was given as a traffjc profjle?)

• Shaping (infmuencing the fmow of packets fed into the network

to adapt to agreed resource picture)

• Scheduling
• Bufger management

Leaky bucket

• Smooth traffjc fmows
• Hard upper limit on rate
• Ineffjcient use of network

resources

Token Bucket

• Token Bucket mechanism, provides a means for limitjng input to

specifjed 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 admitued packets is less

than or equal to (r t + b).

Token bucket

• Arrival profjle can be described in terms of a pair (r, b)

where r is the average bit rate, and b is an indicatjon

• f burst size.

Scheduling

• Which packet should be forwarded at the

network layer when there is a queue?

– Which QoS metric should be prioritjsed?

Scheduling

• FIFO scheduling

– No QoS possible

• Priority scheduling

– One queue for each priority – Guaranteed service for high priority fmows – Risk for starvatjon! – 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 proportjonal

fairness (i.e., no starvatjon)

• Works as follows:

–

Assign a logical queue for each fmow

–

Serve an infjnitesimal amount from each queue

1 2 3

GPS approximatjons

• 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 fmow should be of the same size

Weighter Fair Queueing (WFQ)

• Approximates GPS
• Idea: serve packets according to fjnish order
• f GPS

– Not possible, while being work conservatjve (requires

clairvoyance)

Problematjc case

Packet Arrival time Length Prio 1 5 2 2 10 3 3 1 5 4

WFQ idea

• Close enough: serve packets according to

fjnish order of GPS as known at any given tjme

• Also used in CPU scheduling: default

scheduler in Linux kernel ”Completely Fair Scheduler”

WFQ bounds

• If fmows follow leaky bucket (r,b) then the maximum delay experienced

by a packet in burst b_i:

• For K hops:

R: Service rate wi: weight of flow i Lmax : maximum packet size, Cj output link rate for node j

Class-based link sharing

• Hierarchical allocatjon of the bandwidth

according to traffjc classes

• Each class allocated a max share under a

given interval, and the excess shared according to some sharing policy

Usenet News User type A 40% User type B 60% Real-time 30% ftp 5% Real-time … Link

… … … …

Bufger management

• Scheduling works as long as bufgers are

infjnite

– In reality bufgers (queues) get full during overloads – Shall we drop all the packets arriving afuer the overload

starts?

• Bufger management is about determining

which stored packets to drop in preference to incoming ones

– Can adopt difgerentjated drop policies

QoS: Across network nodes

• IP datagrams delivered with best efgort
• IntServ was defjned to deliver IP packets

with difgerentjated treatment across multjple routers (1994)

• Introduced 3 service classes:

– Best efgort – CL: Controlled Load (acceptable service when no

• verload)

– GS: Guaranteed Service (strict bounds on e-to-e delay)

IntServ

• Each router keeps a sofu state for each fmow

(a session) currently passing through it

– GS: the token-bucket-based requirements from a fmow

induce a max local delay in each router

• The sofu state created with a reservatjon

scheme RSVP, and refreshed while the session is in progress

QoS specifjcatjons in Intserv

• T-spec (traffjc specifjcatjon)

– A token bucket specifjcatjon

• token rate - r
• bucket size - b
• peak rate - p
• maximum packet size - M
• minimum policed unit - m
• R-spec (reservatjon specifjcatjon)

– Service Rate – R

• The bandwidth requirement

– Slack Term – S

• The delay requirement

Sending Tspec & receiving Rspec

Source RSVP routers

PATH RESV

Destination

Diffjcult to deploy in large scale

• IntServ has met resistance for several

reasons, including:

– Dynamic and major changes in reservatjon – Not all routers RSVP enabled – Set up tjme can be proportjonately long compared to

session tjme

– Interactjve sessions need to set up at each end

DifgServ (1998)

• Based on resource provisioning (for a given SLA)

as opposed to reservatjon

• Applied to traffjc aggregates as opposed to single

fmows

• Forwarding treatment as opposed to e-to-e

guarantees

• Edge routers label packets/fmows upon forwarding

to next domain, and accept only in-profjle packets when acceptjng from other domains

Service classes

• Best efgort
• Expedited Forwarding (EF)

– low-loss, low-latency traffjc

• Assured Forwarding (AF)

– assurance of delivery under prescribed conditjons

Two-bit difgserv edge router (simplifjed)

Packet Marked? Token available? Token available? Clear A bit Drop packet Forwarding engine A set P set Token Token No No Not marked

Scalability of DifgServ

• Admission control is now at edge nodes not

every path on a route

• No set-up tjme and per-fmow 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

Spotjfy Android applicatjon that implements simple traffjc shaping techniques, reducing selected applicatjon features’ energy consumptjon over 3G networks by 22-54% during music playback.”