QuaSAQ: Enabling End-to-End QoS for Distributed Multimedia Databases

1. QuaSAQ: Enabling End-to-End QoS for Distributed Multimedia Databases Yicheng Tu, Sunil Prabhakar, Ahmed Elmagarmid, and Radu Sion Department of Computer Sciences Purdue University USA QuaSAQ

2. Talk roadmap • The Problem • Our solution • The QuaSAQ architecture • Offline media processor • QoP Browser • Quality Manager • The QuaSAQ prototype • Experimental results • Conclusions QuaSAQ

3. The Problem: QoS in Multimedia Databases • Multimedia DBMS: an area with well-established research results • Data model • System architecture • Storage • Content-based retrieval • All above are about how to get the query result • What about the delivery of the query result? • Size are huge • QoS Requirments QuaSAQ

4. What about system support of QoS? • OS or middleware • End-to-end style • Fail to capture user preference on QoS, thus end-to-end guarantees are hard to accomplish • Process may not be the basic computation unit in M-DBMSs. • OS/middleware only entertain processes or threads (?) End-to-End QoS guarantees QuaSAQ

5. QoS support as a part of the DBMS • Querying the DB with quality parameters • Users do not need to know low-level details • DB generates plans within the QoS bound specified • Cost evaluation towards various global optimization goals • Throughput • Utilizing current system QoS support to deliver the query results • Theory meets practice: prototyping is essential QuaSAQ

6. QoS support as part of DBMS: How? • Our proposal: A Quality-of-Service-Aware Query Processor (QuaSAQ) that allows database users to specify quality parameters for the media objects retrieved by queries and QoS-guaranteed delivery of these objects while maintaining system-level performance goals • Our approach: • Augment the query evaluation and optimization modules to directly take QoS into account • Challenges: • Mapping the high level QoS to low level QoS; • Generation of QoS-related plans and cost estimation; • Presentation of media objects with end-to-end QoS guarantee; • A M-DBMS on which we may build our QuaSAQ prototype QuaSAQ

7. QuaSAQ architecture • Major components • Offline multimedia processor • Online components • QoP Browser • Quality Manager • QoS APIs QuaSAQ

8. QuaSAQ architecture: Offline components • Replicate media objects by transcoding them into copies with different QoS/formats • Static adaptation in multimedia terminology • Improve flexibility • Test run the delivery session to get the estimated resource use • Fill in the metadata with above info QuaSAQ

9. QuaSAQ architecture: QoP Browser (continued) QoP Browser structure QuaSAQ

10. QuaSAQ architecture: QoP Browser • Users enter user-level QoS (QoP) parameters • Qualitative parameters • Improve flexibility by honoring user profile • ‘High’ resolution --> 352x288 • QoP browser components: • User Profile: contains QoP to application QoS mapping as well as user related statistics • Query Producer: generate queries with QoS requirements based on info from user query input (GUI-based) and User Profile • Plan Executor: running selected plan. Handles media processing, presentation, synchronization, and renegotiation. QuaSAQ

11. QuaSAQ architecture: Quality Manager Quality Manager Structure QuaSAQ

12. QuaSAQ architecture: Distributed Metadata Engine • Need to add metadata about quality of each media object • Used by Plan Generator and Cost Estimation module • Metadata types: • Content Metadata: visual and semantic descriptors for media query, search, and retrieval, provided by underlying M-DBMS • Representation Metadata: Media objects with different quality characteristics are distributed in the database. In the form of application QoS. Includes: resolution, color depth, frame rate, file format, encryption algorithm used. • Distribution Metadata: describe the physical locations of the media objects such as paths, servers, proxies. In practice, only the object ID and file path of each object are stored. • QoS Profile: resource consumption of media object delivery • Metadata may also be distributed QuaSAQ

13. QuaSAQ architecture: Plan Generator • Generating plans that enable the execution of the composite QoS-aware query from the Query Producer • For now, leave the normal non-QoS query processing part unchanged, plans takes care of video delivery only. • Search space of plans: combinations of server activities • media repositories, target objects, and video processing procedures (encoding, filtering, encryption …), QuaSAQ

14. QuaSAQ architecture: Runtime Cost Evaluator • Sorts plans by cost • Basic Cost Model (static) in DBMS: • Cost = CPU time for query processing + Object retrieval time from disk + Communication and data transfer time • Refined Cost Model • dynamic, taking changing system status into account • Various (global) optimization goals • Our proposal: cost model based on estimated resource use • Cost evaluation by Cost Efficiency: • Meaning: utility gain divided by cost consumption QuaSAQ

15. Cost evaluation: maximize throughput Lowest Resource Bucket (LRB): QuaSAQ

16. QuaSAQ architecture: QoS APIs • Unified API and implementation module that communicates and controls underlying APIs. • Functionalities required: • Resource monitoring • Resource reservation • Renegotiation • Follow design and implementation strategies of QualMan (Narhstedt et al., 1999) and GARA (Foster et al., 2000) prototypes QuaSAQ

17. QuaSAQ: implementation issues • Built on VDBMS, a DBMS that supports complex multi-feature queries, content-based searching, and streaming for digital videos. • VDBMS is developed from the open-source object-relational database engine PREDATOR (Seshadri, 1998) and persistent storage manager Shore (Carey et al., 1994). QuaSAQ augments PREDATOR with some modifications to Shore. QuaSAQ

18. QuaSAQ: design and implementation issues (continued) • A distributed version of VDBMS • Data distribution: multiple copies of the same video with different presentation properties • Object identification – 12-byte Object ID • QoS API: GARA QuaSAQ

19. Experimental results: QoS guarantees • Compare QuaSAQ with original VDBMS, both real systems • Metrics: inter-frame delays, data loss ratio • Performance under high system contentions • Server-side data shown below: QuaSAQ

20. Experimental results: QoS guarantees (continued) • Client-side data • Accuracy: measured inter-frame delay divided by theoretical inter-frame delay • SD: standard deviation • QoS API does the job • Data collected under high system contentions below: QuaSAQ

21. Experimental results: system throughput (continued) • Now QoS API itself is not good enough • Outstanding jobs (a) vs. accomplished jobs (b) QuaSAQ

22. Experiments: throughput under new cost model • Compared with a random cost model • Outstanding sessions (a) vs. rejected requests (b) QuaSAQ

23. Summary • System QoS support may not be applicable for M-DBMS as it lacks user-level support • We argue for a QoS manager as part of the M-DBMS query processing/optimization module • QoS in M-DBMS brings up interesting issues to query processing such as cost model • Cost evaluation follows different rules and optimization goals • A prototype of QoS-aware M-DBMS based on VDBMS • More research: • More refined cost evaluation strategies • Is the new view on cost models applicable to other DBMSs? • Dynamic QoS-aware replication • A more complete implementation of QuaSAQ QuaSAQ