Post on 17-Jan-2016
description
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?