Quality of Service - QoS

1. Quality of Service - QoS 2007

2. Outline Integrated Services in the Internet service definitions, protocol support architecture framework algorithms support Differentiated service Intserv over Diffserv Engineering for QoS

3. 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?

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

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

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

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

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

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

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

11. 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 of the failure

13. Implementation Framework (3)---- Implementation Reference Model for Routers Routing Messages Routing RSVP RSVP messages Control Plane Admission Control Data Plane Forwarding Table Per Flow QoS Table Data In Route Lookup Classifier Scheduler Data Out

14. Outline Integrated Services in the Internet service definitions, protocol support architecture framework algorithms support Differentiated service Intserv over Diffserv Engineering for QoS

15. What Is Still Missing? • Classification algorithm • Scheduling algorithm • Admission control algorithm • QoS Routing algorithm

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

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

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

23. 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?