Quality of Service - QoS

2007

Outline• Integrated Services in the Internet

– service definitions, protocol support

– architecture framework

– algorithms support

• Differentiated service

• Intserv over Diffserv

• Engineering for QoS

What is the Problem?

• Goal: support for wide variety of applications:

– Interactive TV, IP telephony, on-line gamming, (distributed simulations), VPNs, etc

• Problem: deal with network congestion• During congestion all packets are treated the same

– All packets get the same delay

• Only control possible at end-hosts– Feedback loop too large (e.g., 100s of ms) for real-time ap

plications (e.g., interactive communication)

– Trust issue how can you trust users that will react properly in case of congestion?

Two Approaches for ProvidingQoS on the Internet

“Freeway model” -- integrated services Internet (intserv)– Build a dedicated highway or “circuit” between

communicating points (VIP) “Doctor’s model” -- differentiated services (diffser

v)– Mark a doctor’s vehicle (e. g.,ambulance) or “p

acket” to get priority the road and limit the percentage of such high- priority vehicles in the total traffic mix (fire-engine, policeman)

A Solution: 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 serv 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

Integrated Services 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

IETF Service Classes Service can be viewed as a contract between netwo

rk and communication client Three common services

Best-effort (“elastic” applications) Hard real-time (“real-time” applications)

Guaranteed service (RFC) Intolerant GS guaranteed QoS control service

equivalent to CBR+VBR-rt in ATM Soft real-time (“tolerant” applications)

Controlled-load service (RFC2000) Tolerant GS controlled link sharing predictive service - RFC1994

similar to VBR-nrt

Guaranteed Service - Intolerant GS (hard real-time)

Service contract• absolute, strict• network to client: guarantee a deterministic up

per bound on delay for each packet in a session di ≤Di

• 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

Controlled-load Service - Tolerant GS (soft real-time)

Service contract• statistical, approximate• network to client: similar performance as an

unloaded best-effort network – nominal mean delay, but can tolerate

“occasional” variation• 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

Implementation Framework (1) Four components:

-- packet classifier, scheduler, admission control routine, reservation setup (signaling) protocol

• Classifier

-- each incoming packet must be mapped into some class; all packets in the same class get the same treatment from the packet scheduler

• Scheduler

-- manages the forwarding of different packet streams using a set of queues and other mechanisms like timers

Implementation Framework (2)• Admission control

-- implements the decision algorithm that a router or host uses to determine whether a new flow can be granted the requested QoS

-- admission control is sometimes confused with policing or enforcement, which is a packet-by-packet function at the “edge” of the network to ensure that a host does not violate its promised traffic characteristics. We consider policing to be one of the functions of the packet scheduler.

• Reservation setup protocol (RSVP)

-- create and maintain flow-specific state in the endpoint hosts and in routers along the path of a flow

12

Role of RSVP in the Architecture

• RSVP is a signaling protocol that applications may separate with Intserv

• Intserv/RSVP architecture is current prevailing model

• Signaling protocol for establishing per flow state• Carry resource requests from hosts to routers• Collect needed information from routers to hosts• At each hop

– consults admission control and policy module– sets up admission state or informs the requester o

f the failure

Implementation Framework (3)---- Implementation Reference Model for Routers

Admission Control

Data InData Out

Con

trol P

lan

eD

ata

Pla

ne

Scheduler

Routing Routing

MessagesRSVP

messages

Classifier

RSVP

Route Lookup

Forwarding Table Per Flow QoS Table

Outline• Integrated Services in the Internet

– service definitions, protocol support

– architecture framework

– algorithms support

• Differentiated service

• Intserv over Diffserv

• Engineering for QoS

What Is Still Missing?

• Classification algorithm

• Scheduling algorithm

• Admission control algorithm

• QoS Routing algorithm

Measurement-based admission control

• Predictive service offers a fairly, but not absolutely, reliable bound on packet delivery times

• MBAC relies on measurements of the delay and bandwidth

MPEG Trace Statistical Parameters

• Trace name Mean-bit St.variance Peak/Mean Delay Bound

• Fuss 27129 25969 6.9 0.0416

• News 15358 19506 12.4 0.0422

• Lambs 7312 11196 18.4 0.0298

• Figure 1. The one-link topology

Single-Hop Simulation Results• Trace name Guaranteed Predictive

• %Util #Actv %Util #Actv

• Fuss 15 10 53 36

• News 8 10 48 58

• Lambs 5 14 40 102

• EXP1 46 144 80 250

• EXP2 28 28 76 75

• EXP3 2 18 62 466

• POO1 7 144 74 1637

• POO2 3 38 64 951

Why did IntServ fail?

• Economic factors

–Deployment cost vs Benefit

• Is reservation, the right approach?

–Multicast centric view

• Is per-flow state maintenance an issue?

• What about QoS in general?