Building an Adaptive Multimedia System using the Utility Model

1. Building an Adaptive Multimedia System using the Utility Model Lei Chen, Shahadat Khan, Kin F.Li & Eric G.Manning PANDA Group, University of Victoria Victoria, British Columbia, Canada

2. Overview • The problem • The Utility Model (UM) • Layered Coding and Transmission (LCT) • How to apply the Utility Model to LCT • The Quality Utility Extension • Unix Kludges • Implementation & Experimental Results

3. The Problem: • How to share resources in a multimedia system? • Contention for resources by competing applications but • Multimedia real-time constraints demand resource guarantees to guarantee QoS

4. For example ... File Transfer Bandwidth y Bandwidth x Video- on- demand Playback Total Bandwidth z (x+y > z) Receiver

5. Our solution: apply the Utility Model to Layered Coding and Transmission

6. We will • Optimize server revenue (utility) while • fully respecting all resource constraints demanded by hard QoS guarantees by on-line session admission & upgrades • devise a bidding HMI protocol

7. maximize U = å ui(Qi) The Utility Model (UM) session i bronze silver gold Quality Qi session utility function resource mapping session utility ui(Qi) session resourcesr (Qi) system utility objective system resource constraints å r (Qi) £ R

8. The Utility Model (UM) • defines relationships among • quality profile, • quality-resource mapping, • session and system utility, • application and system resource constraints, • formulates the Adaptive Multimedia Problem (AMP): Given: quality-resource mappings and quality-utility mappings, maximize some system utility function, subject to resource constraints.

9. u=8 p=4 u=15 p=8 u=10 p=5 Pick items to maximize weight (utility) U=Su, subject to volume constraint (resource constraint): Sp39 Knapsack problems:

10. UM as an MMKP problem • Let: • stones be sessions at QoS levels • piles of stones be sessions • volume be multidimensional (multiple resources): • Choose: • at most one stone per pile • to maximize revenue (weight) • subject to all resource constraints (multidimensional volume)

11. Solving the AMP: u=30 p=15 m=21 u=50 p=20 m=22 u=20 p=8 m=10 u=20 p=10 m=8 u=25 p=15 m=15 u=8 p=4 m=5 u=15 p=8 m=7 u=10 p=5 m=4 • Pick at most one item from each stack in order to maximize U=Su, • subject to resource constraints: Sp39 • Sm35 • i.e. map AMP to a Multiple-choice Multi-dimensional 0-1 Knapsack Problem (MMKP):

12. UM as an MMKP • Solve the MMKP • algorithm BBLP gives optimal solutions • heuristic HEU gives approximate but fast solutions • 300 msec for moderate problems; • suitable for realtime session admission control

13. Layered coding: E1 E2 B B codeword E1 Base quality improvements B: crude image -bronze B +E1: better - silver B+E1+E2: still better - gold

14. Layered Coding and Transmission • Layered coding methods: • spatial layering (e.g. JPEG, MPEG, Pyramid coding, Sub-band coding) • temporal layering (e.g. Motion-JPEG, H.261, DVI, MPEG-2, etc)

15. Layered transmission by multicast: • Send each part of the codeword as a separate multicast group • the more groups received, the better the quality • Layered transmission methods: • IP Multicast and MBone • RLM ( Steve McCanne, UCB) • DSG (Georgia Tech. Inst.) • LVMR (by Xue Li, Georgia Tech.)

16. Using the UM: • Receiver maps quality levels into resource requirements • UM selects the quality level based on available resources

17. CPU BWin BWout Using the UM: T The Utility Model Quality selection Video-on-Demand Playback E2 gold E1 silver bronze Base Receiver

18. Questions • How to design the interface between LCT and the UM? • What resources need to be monitored? • What resources can be monitored? (using an off-the-shelf OS) • What resources can be reserved? • How? (Major Operating Systems problems )

19. More Questions ... • How to derive quality-resource mappings? • How to use the UM in an obsolete* best-effort environment, i.e. • the present Internet • off-the-shelf operating systems (Unix, Windows, MacOS) _____________________ * from the viewpoint of multimedia with QoS

20. Demonstrations • best-effort system: • the UM adapts by scaling back QoS levels of the sessions in its domain • reservation based system: • all resources & sessions in UM’s domain, so • UM optimally sets QoS levels of all sessions.

21. The Unix QUE • Unix Quality Utility Extension (QUE) • provides an extension to a traditional OS for QoS management • based on the UM • estimates quantities which cannot be easily measured in Unix

22. Unix QUE • implements the concepts of the UM: session profiles, quality-resource mapping, session and system utility, and resource constraints; • supports : • admission control and • quality adaptation (HMI bidding protocol )

23. QUE Components & Interfaces • components: • Utility Model Engine (UME) • the OS • applications

24. QUE Components & Interfaces • Interfaces • The Quality Management Interface(QMI) - between the UME and applications • The Graphical User Interface(GUI) - between the UME and users • The Resource Reservation and Monitoring APIs - between the UME and OS;

25. User Obtain Services Start Application QoS Mapping Change Adaptation Status Admission Request or QoS Mapping Change GUI Services Management Utility Model Engine Applications QMI Admission Reply or Quality Change Reservation Agent Resource Monitor Consume Resources Reserve get usage Service API Resource Reservation API Resource Monitoring API Operating System QUE components:

26. QUE: Admission Control (HMI protocol) • UME must guarantee each session’s minimal quality; (by reserving the minimal resources required) • a session is accepted iff • enough free resources to provide minimal QoS, and • increase in system utility ($$) • sessions must obey UME’s adaptation decisions

27. HMI protocol:Quality Adaptation occurs when new session admitted, a session’s QoS mappings changes, a session is terminated, available resources change. Application Application 2 Application Utility Model Engine Adjust reservation in system resources 1 Resulting changes in resource usage New / Drop / Change session profile 3 2 1 Available resources change Operating System

28. QoS Mapping • quality-utility mapping • refine the quality-resource mapping: • quality-methods mapping • method-resources mapping session i bronze silver gold quality-methods mapping operating quality Qi QoS scaling methodmi(Qi) method-resources mapping session utility function resource mapping resource requirementsr (mi) session utility ui(Qi) session resourcer (Qi) system utility objective system resource constraints maximize U = å ui(Qi) constraint å r (Qi) £ R

29. (gold, silver, bronze) User-level QoS Video: 30 fps HDTV Audio: surround Image: hi-res color Consistency: tight Latency: low Video: 15 fps VHS Audio: stereo Image: low-res color Consistency: loose Latency: medium Video: 5 fps M-JPEG Audio: mono Image: gray scale Consistency: none Latency: high Application-level QoS Method 2 Method 3 Method 1 set_fps(15, VHS); set_sound(stereo); set_img_size(lo_res_c); consis_grp(join_base); ... set_fps(5, mjpeg); set_sound(mono); set_img_size(grey); consis_grp(none); ... set_fps(30, HDTV); set_sound(surround); set_img_size(hi_res_c); consis_grp(join_all); ... Other Methods CPU: 30% in BW: 5 Mbps out BW: 512Kbps CPU: 20% in BW: 384 Kbps out BW: 64 Kbps CPU: 10% in BW: 56 Kbps out BW: 14.4 Kbps System-level QoS The QUE (cont.) • Example:

30. Gold Gold Gold $100 $100 $100 void set_fps (30); void set_fps (30); void set_fps (30); in,out,cpu (30, 15, 25) in,out,cpu (30, 15, 25) in,out,cpu (30, 15, 25) The QUE (cont.) • QoS Agents: • per-session proxy • provides QoS mappings • maintains session profile • handles communication between session and UME. Map Quality-Utility Map Quality-Methods Application Utility Model Engine Admission Request Session Profile QoS Agent Admission Reply Quality Change QMI Consume Resources Service API Operating System

31. OS requirements: • OS must be able to • allocate resources to sessions as decided by QUE • enforce allocations on misbehaving sessions • measure per-session consumption of each resource & report results to QUE

32. Meanwhile (in the Unix world) . . . • No enforceable resource allocation available in Unix • No per-session resource consumption data • System-level monitoring of consumption via /proc • Resource consumption estimated as follows: CPU T = user _____________________ (% total cpu cycles/sec) user + nice + idle + OS Tx T = totalTx T - totalTx T-1 (packets / sec ) RxT = totalRx T - totalRx T-1 (packets / sec ) RHS quantities obtainable from /proc in Unix.

33. Estimating resource consumption in unix ... • define: • raw - total amount of a resource provided by the hardware • manageable - available to the UME • unmanageable - used by applications out of the UME’s domain • raw = manageable + unmanageable • allocated - required to support operating QoS of admitted sessions • free = manageable - allocated : the unused resource • reserved - required to support minimal QoS of admitted sessions

34. Getting around a unix defect - no reservations: • In an unreserved system (unix) • allocations cannot be enforced • applications contend for resources at run-time; • so manageable resources must be adjusted to avoid contention • but contention cannot be detected at OS level: (one cannot distinguish full utilization from contention.)

35. raw raw Quality adaptation result manageable manageable monitored allocated unmanageable free free Resource partitions in the UME at time t-1 Resource usage reading at time t Question: How should the UME partition the resource at time t ? Contention Avoidance (the problem): • Only raw T and monitored T are measurable; how to infer manageable T ?

36. Estimating Manageable for Contention Avoidance: assumeapplications do not over-consume initial condition: manageableT=0 = 95% * rawT=0 Now monitored T < allocated T => no out-of-domain work => manageable T = 95% * raw T monitored T > allocated T => out-of-domain work => manageable T = raw T - unmanageable T = raw T - ( monitored T - allocated T-1 )

37. Systems providing resource reservation: • None of the above is necessary

38. Implementation and Results • Prototype implementation • implemented the QUE over Linux • implemented VoD, which uses LCT • implemented QFTP, a rate controllable file transfer program

39. Experiment setup • QUE used in client Server A Server B spring.csc.uvic.ca 142.104.101.11 Solaris 2.4 beet.csc.uvic.ca 142.104.101.30 Redhat Linux 2.1 1.6 Mbps 1.6 Mbps 1.6 Mbps 1.6 Mbps 10 Mbps Ethernet 1.6 Mbps 1.6 Mbps Client C (QUE) pepper.csc.uvic.ca 142.104.101.29 Redhat Linux 2.1

40. Implementation and Results (cont.) • Best-effort mixed system (like today’s Internet) • VoD (in UM’s domain) starts first. • FTP (outside UM’s domain) seizes most of the inbound bandwidth. • UME required to scale back the quality of VoD • VoD customer cancels service agreement, sues provider Client C FTP Inbound bandwidth Quality Utility Extension From Server A Utility Model Engine contention From Server B Scale back ! VoD

41. QUE obeys system and application resource constraints. • QUE: • dynamically adjusts manageable resource; • adapts application’s QoS to avoid contention; • reserves required resources for applications’ minimal QoS; • does not scale back beyond the reserved level of the resource.

42. Reservation based system (future Internet, modern OS): • VoD preferred over QFTP (more utility offered) • preference then changed to favour QFTP (its $$ increased) • UME required to optimally adapt both sessions’ QoS Client C Quality Resource Util bronze 40 pps $5 silver 60 pps $10 gold 120 pps $15 Quality Utility Extension QFTP silver silver Inbound bandwidth From Server A Utility Model Engine provision From Server B gold Quality Resource Util bronze 25 pps $50 silver 35 pps $75 gold 60 pps $100 VoD

43. Implementation and Results (cont.) • QUE adapts both applications according to UM decisions: • predictive system behavior • increased system utility • optimal resource allocation among applications • happy customers

44. Performance • Pentium 166MMX with 40MB memory • 300ms (mean) for admission control • less than 2ms for quality adaptation

45. Summary • The Utility Model: maximizes revenue while fully respecting all QoS guarantees • The application of UM to LCT • The Quality Utility Extension • Kludges to avoid contention in an elderly OS with no resource reservation • Implementation and experimental results