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 2019/2/17 QuaSAQ

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

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 QoS Layer Parameters Application Frame size, Frame rate, Color depth, SNR, Security System CPU cycles, memory buffer, I/O bandwidth Network Delay, Jitter, Packet loss, Network throughput 2019/2/17 QuaSAQ

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 2019/2/17 QuaSAQ

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 2019/2/17 QuaSAQ

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 2019/2/17 QuaSAQ

QuaSAQ architecture Major components Offline multimedia processor Online components QoP Browser Quality Manager QoS APIs 2019/2/17 QuaSAQ

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 2019/2/17 QuaSAQ

QuaSAQ architecture: QoP Browser (continued) QoP Browser structure 2019/2/17 QuaSAQ

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. 2019/2/17 QuaSAQ

QuaSAQ architecture: Quality Manager Quality Manager Structure 2019/2/17 QuaSAQ

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 2019/2/17 QuaSAQ

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 …), 2019/2/17 QuaSAQ

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 2019/2/17 QuaSAQ

Cost evaluation: maximize throughput Lowest Resource Bucket (LRB): 2019/2/17 QuaSAQ

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 2019/2/17 QuaSAQ

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. 2019/2/17 QuaSAQ

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 2019/2/17 QuaSAQ

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: 2019/2/17 QuaSAQ

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: 2019/2/17 QuaSAQ

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

Experiments: throughput under new cost model Compared with a random cost model Outstanding sessions (a) vs. rejected requests (b) 2019/2/17 QuaSAQ

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 2019/2/17 QuaSAQ