EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

25
EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001

Transcript of EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

Page 1: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

EE 122: Lecture 15(Quality of Service)

Ion Stoica

October 25, 2001

Page 2: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 2

Limitations of IP Architecture in Supporting Resource Management

IP provides only best effort service IP does not participate in resource management

- Cannot provide service guarantees on a per flow basis

- Cannot provide service differentiation among traffic aggregates

Early efforts- Tenet group at Berkeley (Ferrari and Verma)

- Asynchronous Transfer Mode (ATM)

IETF (Internet Engineering Task Force) efforts - Integrated services initiative

- Differentiated services initiative

Page 3: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 3

Service Classes

Multiple service classes Service can be viewed as a contract between

network and communication client- End-to-end service (multicast and anycast)

- Other service scopes possible, e.g.,

• Aggregates – all packets between to points (not necessary end-hosts) in the Internet

Three common services- Best-effort (“elastic” applications)

- Hard real-time (“real-time” applications)

- Soft real-time (“tolerant” applications)

Page 4: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 4

Example: Integrated Services

Enhance IP’s service model- Old model: single best-effort service class- New model: multiple service classes, including best-

effort and QoS classes Create protocols and algorithms to support new

service models- Old model: no resource management at IP level- New model: explicit resource management at IP level

Key architecture difference- Old model: stateless - New model: per flow state maintained at routers

• Used for admission control and scheduling• Set up by signaling protocol

Page 5: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 5

QoS Network

Flow or session as QoS abstractions

Each flow has a fixed or stable path

Routers along the path maintain the state of the flow

Page 6: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 6

QoS Network Operations

Control plane: admission control- Reserve resources (i.e., link capacity and buffer space)

at every router along the path

Data plane: perform per flow- Classification: classify each packet to the flow it

belongs to

- Buffer management: decide when and which packet to drop

- Packet scheduling: decide when and which packet to send

Page 7: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 7

Control Plane: Admission Control

SenderReceiver

Example: achieve per-flow bandwidth and delay guarantees- Example: guarantee 1MBps and < 100 ms delay to a flow

Page 8: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 8

Control Plane: Admission Control

SenderReceiver

Allocate resources - perform per-flow admission control

Page 9: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 9

Control Plane: Admission Control

SenderReceiver

Install per-flow state

Page 10: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 10

SenderReceiver

Install per flow state

Control Plane: Admission Control

Page 11: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 11

Data Plane

SenderReceiver

Per-flow classification

Page 12: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 12

Data Plane

SenderReceiver

Per-flow buffer management

Page 13: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 13

Data Plane

SenderReceiver

• Per-flow scheduling

Page 14: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 14

Service Classes

Multiple service classes Service can be viewed as a contract between

network and communication client- End-to-end service

- Other service scopes possible

Three common services- Best-effort (“elastic” applications)

- Hard real-time (“real-time” applications)

- Soft real-time (“tolerant” applications)

Page 15: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 15

Service Specification

Loss: probability that a flow’s packet is lost Delay: time it takes a packet’s flow to get from

source to destination Delay jitter: maximum difference between the

delays experienced by two packets of the flow Bandwidth: maximum rate at which the soource

can send traffic

Page 16: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 16

Hard Real Time: Guaranteed Services

Service contract- Network to client: guarantee a deterministic upper

bound on delay for each packet in a session

- Client to network: the session does not send more than it specifies

Algorithm support- Admission control based on worst-case analysis

- Per flow classification/scheduling at routers

Page 17: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 17

Soft Real Time: Controlled Load Service

Service contract:- Network to client: similar performance as an unloaded

best-effort network

- Client to network: the session does not send more than it specifies

Algorithm Support- Admission control based on measurement of

aggregates

- Scheduling for aggregate possible

Page 18: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 18

Traffic and Service Characterization

To quantify a service one has two know- Flow’s traffic arrival

- Service provided by the router, i.e., resources reserved at each router

Examples:- Traffic characterization: token bucket

- Service provided by router: fix rate and fix buffer space

Page 19: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 19

Token Bucket

Characterized by three parameters (b, r, R)- b – token depth

- r – average arrival rate

- R – maximum arrival rate (e.g., R link capacity) A bit is transmitted only when there is an available token

- When a bit is transmitted exactly one token is consumed

r tokens per second

b tokens

<= R bps

regulatortime

bits

b*R/(R-r)

slope R

slope r

Page 20: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 20

Characterizing a Source by Token Bucket

Arrival curve – maximum amount of bits transmitted by time t Use token bucket to bound the arrival curve

time

bits

Arrival curve

time

bps

Page 21: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 21

Example

Arrival curve – maximum amount of bits transmitted by time t Use token bucket to bound the arrival curve

size of timeinterval

bitsArrival curve

time

bps

0 1 2 3 4 5

1

2

1 2 3 4 5

1

2

3

4

(b=1,r=1,R=2)

Page 22: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 22

Per-hop Reservation

Given b,r,R and per-hop delay d Allocate bandwidth ra and buffer space Ba such

that to guarantee d

bits

b

slope rArrival curve

d

Ba

slope ra

Page 23: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 23

End-to-End Reservation

Source S sends a message containing traffic characteristics- r,b,R

- This message is used to computes the number of hops Receiver R sends back this information + worst-case delay (D) Each router along path provide a per-hop delay guarantee and

forwards the message - In simplest case routers split the delay D

S1S1

S2S2

S3S3

SSRR(b,r,R) (b,r,R,3)

num hops

(b,r,R,2,D-d1)(b,r,R,1,D-d1-d2)(b,r,R,0,0)

(b,r,R,3,D)

worst-case delay

Page 24: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 24

Summary

Service: a contract between end-hosts and network

QoS goal: provide better than best-effort services to support new applications with more stringent delay and bandwidth requirements, e.g., IP telephony, videoconferencing

QoS requires to manage flows/aggregates both on data and control plane

Two major proposals:- Integrated Services (this is mostly what we did this

lecture; we’ll do more next lecture)- Differentiated Services (see next lectures)

Page 25: EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001.

[email protected] 25

Administrative Stuff

2nd midterm exam: next Tuesday, November 6 Similar to the 1st midterm exam

- Conceptual questions

- Problems similar to the ones in homeworks

- Close books

- All material up to and including IP Multicast (i.e., lecture on October 16)

4th homework: also handed out next Tuesday We are trying to have a review session for the 2nd

project one week or so before the deadline; details to be announced