TDDD82 Secure Mobile Systems Lecture 6: Quality of Service

Transcription

1 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

2 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

3 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

4 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?

5 CPU Scheduling

6 Non-preemptive vs preemptive

7 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

8 CPU Scheduler

9 Burstiness

10 Burst histogram

11 What is a good scheduler?

12 Scheduling Criteria CPU utilization keep the CPU as busy as possible Throughput # of processes that complete their execution per time unit 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

13 Process First-Come, First-Served (FCFS) Scheduling Burst Time P 1 24 P 2 3 P 3 3 Suppose that the processes arrive in the order: P 1, P 2, P 3 The Gantt Chart for the schedule is: P 1 P 2 P

14 FCFS Performance P 1 P 2 P Waiting time P i = start time P i time of arrival for P i

15 FCFS Performance P 1 P 2 P Waiting time P i = start time P i time of arrival for P i Waiting time for P1 = 0; P 2 = 24; P 3 = 27 Average waiting time: ( ) / 3 = 17

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

17 Can we do better?

18 Yes! Suppose that the processes arrive in the order P 2, P 3, P 1 The Gantt chart for the schedule is: P 2 P 3 P Waiting time for P1 = 6; P 2 = 0, P 3 = 3 Average waiting time: ( )/3 = 3 - much better!

19 Convoy effect Short process behind long process Idea: shortest job first?

20 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

21 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)

22 Example of Non-Preemptive Process Arrival Time Burst Time P P P P SJF with non-preemptive SJF: P 1 P 3 P 2 P Average waiting time = ( ) / 4 = 4

23 Example of Preemptive SJF Process Arrival Time Burst Time P P P P with preemptive SJF: P 1 P 2 P 3 P 2 P 4 P Average waiting time = ( ) / 4 = 3

24 Predicting Length of Next CPU Burst Need to estimate! Based on length of previous CPU bursts, using exponential averaging: + 1. t n =actual length of n th CPU burst 2. τ n+1 = predicted value for the next CPU burst 3. α, 0 α 1 4. Define: τ n=1 =α t n + (1 α ) τ n.

25 +

26 Extreme cases of exponential =0 averaging n+1 = n Recent history does not count =1 n+1 = t n Only the latest CPU burst counts

27 Exponential Averaging All other cases Expand the formula: n+1 = t n + (1 - ) t n-1 + +(1 - ) j t n-j + +(1 - ) n +1 0 Since both and (1 - ) are less than 1, each successive term has less weight than its predecessor

28 SJF is a special case of priority scheduling

29 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 SJF is a priority scheduling where priority is the predicted next CPU burst time

30 Challenge for Priority Scheduling Problem: Starvation low-priority processes may never execute Solution: Aging as time progresses increase the priority of the process

31 What if we make aging the main scheduling factor?

32 Round Robin (RR) Each process gets a small unit of CPU time: time quantum, usually milliseconds. After this time has elapsed, the process is preempted and added to the end of the ready queue.

33 What happens if a new process comes at the same time as another process is preempted?

34 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.

35 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, otherwise too high overhead

36 Example: RR with Time Quantum q = 20 Process Burst Time P 1 53 P 2 17 P 3 68 P 4 24 The Gantt chart is: P 1 P 2 P 3 P 4 P 1 P 3 P 4 P 1 P 3 P Typically, higher average turnaround than SJF, but better response

37 Time Quantum and Context Switches Smaller time quantum more context switches

38 RR: Turnaround Time Varies With Time Quantum

39 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

40 Quality of Service Not Best effort Provide guarantee! Requires: Model of source Model of resource Model of provider

41 QoS Philosophies Service differentiation When there are overloads some connections/packets/applications are preferred to others Fairness All should get something (but how much?) Orthogonal: Adaptation Adaptive ones should adapt to make room for non-adaptive ones

42 Networked applications Edge nodes CPU Power Memory (buffer space) Links Bandwidth Forwarding nodes: buffer space

43 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,

44 Recall lecture 5 Fault-tolerance requires replication Consistent replication requires agreement Agreement requires timeliness guarantees

45 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)

46 Application types Elastic or inelastic Mail or video conference Interactive or non-interactive Voice communication or file transfer Tolerant or non-tolerant MPEG video-on-demand or automated control Adaptive or non-adaptive Audio/video streaming or electronic trading Real-time or non-real-time IP-telephony or A/V on demand (streaming)

47 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

48 Leaky bucket Smooth traffic flows Hard upper limit on rate Inefficient use of network resources

49 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).

50 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.

51 Scheduling Which packet should be forwarded at the network layer when there is a queue? Which QoS metric should be prioritised?

52 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?

53 Generalized Processor Sharing Work conserving (router not idle when there is work to do) Guarantees proportional fairness (i.e., no starvation) 2 1 Works as follows: Assign a logical queue for each flow Serve an infinitesimal amount from each queue 3

54 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

55 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

56 WFQ bounds If flows follow leaky bucket (r,b) then the maximum delay experienced by a packet in burst b_i: R: Service rate w i : weight of flow i For K hops: L max : maximum packet size, C j output link rate for node j

57 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 40% User type B 60% Real-time 30% Usenet ftp News 5% Real-time

58 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

59 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)

60 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

61 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

62 Sending Tspec & receiving Rspec Destination PATH RESV Source RSVP routers

63 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

64 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

65 Service classes Best effort Expedited Forwarding (EF) low-loss, low-latency traffic Assured Forwarding (AF) assurance of delivery under prescribed conditions

66 Two-bit diffserv edge router (simplified) A set Token available? No Token Clear A bit Packet Marked? Not marked Forwarding engine P set Token Token available? No Drop packet

67 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

68 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.