Transcript 8-1_intserv07

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
applications (e.g., interactive communication)
– Trust issue  how can you trust users that will react
properly in case of congestion?
Two Approaches for Providing
QoS on the Internet
“Freeway model” -- integrated services Internet
(intserv)
– Build a dedicated highway or “circuit” between
communicating points (VIP)
 “Doctor’s model” -- differentiated services
(diffserv)
– Mark a doctor’s vehicle (e. g.,ambulance) or
“packet” 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
network 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
upper 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
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
of the failure
12
Implementation Framework (3)
---- Implementation Reference Model for Routers
RSVP
Admission
Control
Forwarding Table
Data In
Route Lookup
Per Flow QoS Table
Classifier
Scheduler
Control Plane
Routing
RSVP
messages
Data Plane
Routing
Messages
Data Out
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
•
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
Delay Bound
Single-Hop Simulation Results
•
Trace name
•
Guaranteed
%Util #Actv
Predictive
%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?