Quality of Service I: Definitions, Services and Architectures

1. Quality of Service I: Definitions, Services and Architectures ANDREW T. CAMPBELL Dept. of Electrical Engineering Columbia University http://comet.columbia.edu/campbell campbell@comet.columbia.edu LECTURE 9 6 November, 1998

2. Reality check • Project proposal • New Intel Lab open for work • Quiz this Tuesday 1.5 hrs. • Take home programming assignment • tutorial Thursday on it • released Friday on Web/email to class • returned Sunday midnight (mail it to mk)

3. QOS I and II • QOS II - a survey • Basics; language, definitions, survey • Architectures: services and mechanisms • QOS II - differential services

4. Observations • Networks, distributed computing the advent of multimedia and the web call for stronger QOS paradigms than todays best effort • What is the QOS that fits? • Is there one QOS for all? • What does QOS mean to the user and the network? • The emergence of end-to-end QOS: a unified approach • The failure of ATM and IEFT model - so where now? • 10 years of research, many fundamental problems resolved but QOS is still in a major state of flux, why?

5. What is Quality of Service? • Means many things to many people • multimedia driver, audio and video coding, operating systems, communication protocols, networks, scheduling and traffic management issues, ORB QOS, architectures, mechanisms, and on and on

6. Different notions of Quality of Service • Different notion of QOS • user view point is perceptive (e.g., MOS testing) • application-level QOS • end-system based QOS • network based QOS • simple network [Keshav,92] definition from QOS workshop • ‘network quality sufficient to satisfy users needs, however they may expressed’

7. utility bandwidth Application-level QOS example

8. End-system QOS issues • Operating system issues • Real-time scheduling, apps, threads • resources • memory, CPU and IO are resources • end-system communication issues • transport • NICs

9. Network-based QOS • QOS metrics • end-to-end delay • variation in end-to-end delay (jitter) • packet/cell loss • bandwidth • shared resources • NICs, links, switches • Historically outside control of user until more recently

10. Todays notion of Network QOS • One-demand establishment of end-to-end QOS • ‘circuit emulation’ approach • ATM network traffic classes and QOS • IETF integrated services • Other views • best effort ‘QOS’ • Adaptive QOS • Differential services QOS • Components • specify, contract and deliver QOS • admission control and services disciples key

11. Notion of a flow and micro-flow • Important service abstraction with QOS • Characteristics • production, transmission and consumption of a single media source (e.g., audio, video, real-time data) governed by a single statement of QOS • simplex, unicast/multicast • generally require admission control and resource reservation and support for heterogeneous QOS • micro-flows • short-lived flows that have similar characteristics and QOS demands (e.g., web transaction of real-time image)

12. End-to-end control • Consider streaming media from a web server to a client • QOS should apply to all flows (e.g., audio and video) from the server, across the network to clients at the point of delivery • ‘open loop’ control issues • end-to-end admission control and resource reservation • coordination of disk and thread scheduling in server • flow/rate control in end-system • packet/cell scheduling in network • monitoring and maintenance of delivered quality

13. Who is doing QOS research? • Distributed systems community • QOS in CORBA for example • Still in early phase • Operating systems community • substantial work done • classic scheduling, e.g., earliest deadline first • still work to do • Networking community • pioneering work • huge amount of work done • recycle going on

14. QOS architecture • End-to-end in nature • Unifying approach across all layers • Generalized Framework • QOS principles • QOS specification • QOS mechanisms

15. QOS principles • integration principle • each resource module (e.g., CPU, memory, NIC, switches, links) traversed must provide QOS configurability, resource assurances and maintenance of flows/sessions/ micro-flows • separation principle • transport, control/signaling and management • transparency principle • app shielded from complexity of underlying QOS control and management, and reduces need to embed mechanisms in app • multiple time-scales principle • guides the division of functionality between architectural modules and pertains to modeling control and management • performance principle • techniques and rules for constructing QOS driven comms, minimizing layered multiplexing, structuring protocols, etc.

16. QOS specification • Capturing application-level QOS and management policy • Different at each layer (apps, transport, network) • Applications • specifies what is required rather than how to achieve it • Encompasses • flow synchronization (e.g., lip synch) • flow performance (e.g., delay, jitter, loss, bandwidth) • level of service (e.g., deterministic, predicative, best effort) • QOS management policy (e.g., QOS violations, actions) • cost of service (e.g., pricing policy dictates behavior)

17. Services and mechanisms • Services • e.g., continuous media, real-time transaction, unreliable/reliable comms • Mechanisms • help to deliver the QOS for the service and should be configurable based on the specification and mapping functions • Characteristics and time-scales • quasi-static resource management (QOS provisioning) • establish, re-negotiate, tear-down • dynamic resource management (control and mgmt) • deals with media transfer phase

18. QOS provision Mechanisms • QOS mapping • admission testing • resource reservation protocols

19. QOS control mechanisms • Flow shaping • Flow scheduling • Flow policing • Flow control • Flow synchronization

20. QOS management Mechanisms • QOS monitoring • QOS maintenance • QOS degradation • QOS availability • QOS scalability

21. QOS architectures • A number of QOS-archietctures have been proposed • standards (IETF, ISO) • telecommunications (TINA, XRM) • computer communications (IntServ, QOS-A) • Operating systems and networking coming together • Examples • IBM Hiedleberg QOS model • Columbia’s XRM (xbind realization) • UPEN OMEGA • Int-serv Architecture • Lancaster QOS-A • ISO QOS Framework • UCB Tenet Architecture

22. Columbia XRM • Five distinct planes • management functions (N-plane): cover OSI functional area for network and systems management • traffic control function comprises • resource control (M-plane) • cell scheduling, call admission, call routing • process scheduling, memory management • control (C-plane) • connection management, call re-negotiation • telebase which resides in the (D-plane) • collectively represents distributed global state that is accessed and shared among all planes (e.g., routing state, call state, resource availability)

23. XRM model

24. XRM’s theoretical underpinings • ATM network oriented • call setup and traffic classes supporting deterministic and probabilistic QOS guarantees • Capacity regions used for network and end-system • schedulable region for network multiplexing point that is used to build end-to-end calls with QOS • traffic classes and hyper-region representation • multimedia capacity region in end-systems • e.g., mpeg flows also hyper-region representation

25. Schedulable region • Real-time bin packing operation • abstraction for cells (i.e fixed sized packets) with certain traffic class characteristics • traffic classes characterized by • cell loss probability, bandwidth, delay constraints • abstraction for a multiplexing point with QOS guarantees that supports 4 cell level traffic classes • circuit emulation, voice and video, data and and network management • resources controlled • switching bandwidth and link capacity • in order to efficiently satisfy QOS requirements of the cell-level, scheduling and buffer management algorithms dynamically allocate communication bandwidth and buffer space

26. IEFT Integrated Services Arch. • Flow spec • a number of traffic classes came and went • predicated service, controlled load, guaranteed delay • bandwidth (no explicit loss metric) • delay (jitter considered to be resolved at end system) • Signaling • RSVP based on multicast heterogenious receiver model • Architecture • packet classifier • admission controller • scheduler • signaling

27. IETF ISA QOS management model

28. Failure of ATM and IETF models • RSVP and Int-serv ran out of steam for a number of reasons • concerns of scalability RSVP/ state management/ aggregation issues for router and high speed • ATM’s ‘circuit emulation’ model may not fit • new softer notion of QOS called differential services • in-band control • longer time resource management • telcos engineering capacity planning • Many issues to solve - jury out • ATM is the only network model for QOS but it languishes • signaling a mess and its not ubiquitous and hyped • QOS model very complex - what does cell loss probability mean to an app and customer

29. Lancaster QOS Architecture (QOS-A) • Hybrid architecture between telecomms and Internet model • Incorporated the notion of ‘integrated QOS’ across layers via planes • APIs with QOS particular focus on end-system transport and support for continuous media • Adaptation (action,events) • QOS mechanisms pushed into the transport as oppose to into the application as in the case of RTP

30. QOS-A Model

31. Comparison of QOS architectures

32. Next week • Jim Kurose’s Open Issues paper • Four approaches to providing QOS guarantee in the network • Tightly controlled approach • Approximate approach • bounding approach • observation approach • Van Jacobson’s premium services • one differential services proposal