Devices & Hardware

A Data Aware Admission Control Technique for Social Live Streams (SOLISs)

Description
A Data Aware Admission Control Technique for Social Live Streams (SOLISs) Sumita Barahmand and Shahram Ghandeharizadeh Database Laboratory Technical Report Computer Science Department, USC Los
Published
of 18
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
A Data Aware Admission Control Technique for Social Live Streams (SOLISs) Sumita Barahmand and Shahram Ghandeharizadeh Database Laboratory Technical Report Computer Science Department, USC Los Angeles, California July 20, 2012 Abstract A SOcial LIve Stream, SOLIS, is a live stream produced by a device whose owner is sharing the stream with her friends, granting each friend to perform time shifted viewing for a pre-specified duration. The system buffers this chase data to facilitate its browsing and display. In the presence of many SOLISs, memory may overflow and prevent display of some chase data. This paper presents a novel data-aware admission control, DA-AdmCtrl, technique that summarizes chase data pro-actively to maximize the number of admissible SOLISs with no memory overflow. It is designed for use with multi-core CPUs and maximizes utility of data whenever the user s level of satisfaction (utility) with different data formats is available. We use analytical models and simulation studies to quantify the tradeoff associated with DA-AdmCtrl. A Introduction Social networking sites such as RAYS [5], Qik [23] or Bambuser [4] enable their members to invite their friends to view a live stream from their devices. A streaming device might be a smartphone such as an iphone or an inexpensive wireless consumer electronic device by a vendor such as Linksys or Panasonic. With RAYS, the owner of a Device may specify a chase duration ( ) for an Invitee. This allows Invitee to time shift view [12, 16, 17] data for the specified duration. The term SOcial Live Stream, SOLIS, refers to device produced streams with this characteristic [6], see Figure 1. The motivation for using streaming devices with a social networking web site is two folds. First, to share a SOLIS with a large number of invitees. Second, to support functionality such as chase display and recording of streams for future recall and sharing. With the first, a device typically supports a handful of simultaneous viewers due to either limited network bandwidth, processing capability, or both. For example, 1 Figure 1: A SOLIS with two chase displays. the Panasonic BL-C131 camera configured to use its wired network connection supports a maximum of 9 to 12 simultaneous displays. When used with a social networking web site, a stream might be shared among thousands of viewers. With the second, the constantly evolving chase data corresponding to the past time units must be buffered on behalf of Invitee. The infrastructure of a social networking site provides this memory 1. Moreover, it may provide sophisticated indexing techniques (using tapestries [7]) to enable the invitee to retrieve the relevant portions of chase data. With a single SOLIS and many invitees with different values, RAYS maintains data pertaining to the maximum value. All viewers share this copy of data and the software enforces the value of specified (by the owner of the device) for Invitee. This means invitees of a SOLIS may join an in progress SOLIS late without requiring additional memory. However, a new SOLIS request requires memory equal to the maximum specified by the owner of Device for invitee. A key deployment question is the configuration of the server and its memory size. One may over provision for the maximum number of SOLISs and their values. This is a reasonable approach given today s inexpensive price of memory. However, if either the anticipated number of SOLISs is unknown or the size of the device formatted data changes dynamically, then a deployment may run out of memory and evict chase data. Every time an invitee references this evicted data, the system may either ignore the request and/or report the data is missing, reducing the quality of service. One approach to this limitation is to require the system administrator to detect memory overflows and extend the system with additional memory. This detective approach has its own limitations. First, from the first time an overflow is detected until additional memory is obtained, SOLIS requests may overflow memory repeatedly. Second, configuring a server with additional memory may require some down time. 1 An alternative is to buffer this data on the client device. A limitation of this approach is that the client device may have insufficient physical memory to buffer time units of data. 2 An alternative approach is to employ a Data Aware Admission Control, DA-AdmCtrl, technique. When a new SOLIS request arrives to the system and there is insufficient memory to support its chase data, DA- AdmCtrl starts to summarize past and incoming data pro-actively in order to admit the new request. A Summarization Technique, ST, may either reduce the resolution (quality) of data in order to reduce its memory requirement or convert device produced data into a format that can be used by another ST to reduce its size, see discussions of Section E. DA-AdmCtrl admits a new SOLIS request as long as there is sufficient memory to accomodate its chase data. Otherwise, it rejects the SOLIS request. The system may allow this request to proceed as a live stream with no chase display. With multi-core CPUs, DA-AdmCtrl employs several ST processes to summarize different data chunks simultaneously where each data chunk corresponds to a portion of chase display of one or more SOLISs. There may exist dependencies between the STs such that the summary format produced by one ST is the input to another ST. For example, Figure 3.a shows one inter-dependency named Deep-Desc. It consists of four different data formats: produced by a device with average size of 1000 KB per unit of time, and three summarized formats,, and with their sizes shown in each node (number on an edge denotes the average service time of ST to process its input data format to produce its output data format). DA-AdmCtrl is flexible enough to support arbitrarily complex inter-dependencies between STs as long as they are trees. The primary contribution of this paper is a data aware admission control technique that admits SOLIS requests with the objective to maximize utility of data with no memory overflow. Utility quantifies the user s level of satisfaction with a data format (produced by either the device or an ST). When the utility for all data formats is identical (chase viewer does not discriminate between the different data formats), the admission control selects those data format(s) that prevent memory overflow. In addition to considering the available memory at one instance in time, the admission control ensures the summarization rate for the chase data is either equal to or higher than the rate of data arrival by the currently active SOLISs, preventing memory over-flow. This analysis considers the number of cores, the service time of STs, and their inter-dependencies. The following example illustrates these concepts. Example 1: Consider three SOLISs, each with time units. Each SOLIS produces 1000 KB data in format in each time unit, =1000 KB (see Table 1). The system is configured with one ST that summarizes the incoming high resolution data to a low resolution format that is ten times smaller, ! =100 KB. Assume the summarization process requires 2 time units. At first glance, the amount of required memory for these 3 SOLISs might appear to be 1500 KB, #%$& '$( !. However, as shown in Figure 2, assuming a system with more than six cores, the total amount of required memory during steady state is 7200 KB. At any instance of time, say 7th time unit, the occupied memory must accommodate three different SOLISs producing ) data (3 $ 1000 KB), ) data produced at time 6 that is being summarized actively (3 $ 1000 KB), data that is being produced actively by the summarization technique (3 $ 100 KB), and data pertaining to summary data corresponding to Time 5, 4, and 3 (3 $ 3 $ 100 KB). The 3 Memory(KB) Time Figure 2: Memory usage for three SOLISs of Example 1. later must be maintained in memory because =5. The numbers in this simple example scale. The amount of required memory with 3000 SOLISs is approximately 7 GB assuming a system with 6000 cores. If the system is configured with less memory than what is required, then the admission control might be forced to reject some of the arriving SOLIS requests even though the system is configured with many cores to summarize data. At least 6000 cores are required because the time to summarize formatted data is twice the inter-arrival time for data. Fewer than 6000 cores requires more memory than 7 GB, see discussions of Equation 1. * The rest of this paper is organized as follows. Section B presents related work. Details of DA-AdmCtrl are provided in Section C. We quantify the tradeoffs associated with DA-AdmCtrl in Section D. Section E describes flexibility of DA-AdmCtrl and its use in two different contexts. Section F offers brief conclusions and future research directions. B Related Work Admission control techniques prevent a newly arrived request from disrupting currently active requests and their observed quality of service [11, 25]. They do so by monitoring either the amount of available memory, disk [26, 18, 28, 1] and network [2, 8] bandwidth, or a combination of these resources. For example, admission control techniques developed for video-on-demand servers consider disk bandwidth in combination with the available memory to control how many simultaneous requests may stream data from the disk without overflowing memory [13, 10, 22, 9, 15, 20]. Similarly, multi-layer encoding techniques are employed to control the bandwidth requirements of a stream in the presence of bursty background load that exhausts the available network bandwidth [21, 24, 27]. These studies strive to deliver continuous media in a timely manner to prevent a client s display from starving for data. Our proposed technique is different because it focuses on live streaming data and how to summarize this data proactively in order to admit requests without overflowing memory. Note that once data is lost (due to memory overflows), the original cannot be re-constructed. Similarly, once a lossy summarization technique reduces the resolution of data to reduce the memory requirement of a SOLIS, the original data is lost permanently. 4 Several studies focused on recording of continuous media produced by cameras used by news organizations [19, 3, 14]. Their proposed techniques write data to magnetic disk drives without overflowing memory of a server as a temporary staging area. These studies highlight the limited bandwidth of magnetic disk drives, restricting the number of admitted requests severely. While the bandwidth of disks continues to be a limiting factor today, the cost of memory has dropped significantly to deliver inexpensive servers with tens of Gigabytes of memory 2. These trends are the primary motivation for our proposed admission control technique. By using memory only, we can support a much larger number of concurrent requests than [19, 3]. Our admission control technique is novel for two reasons. First, it quantifies memory requirements of alternative summarization techniques with multi-core CPUs. Second, it is flexible enough to consider arbitrarily complex inter-dependencies between different summarization techniques as long as they are trees. We introduced the concept of SOLIS, its user interface, and a buffer replacement technique that summarizes (instead of evicting) data when memory becomes fully occupied in [6]. The replacement technique cannot control the number of SOLISs and, once the number of SOLISs exceeds a threshold, is forced to evict a significant amount of chase data from memory. The proposed admission control technique address this limitation in two ways. First, it summarizes data pro-actively. Second, it does not admit a SOLIS request if it results in memory overflow. C Admission Control Admission control is invoked every time a new SOLIS request arrives to the system. It can be configured to either prevent memory overflow or maximize utility of data while preventing memory overflow. Memory overflow occurs when data pertaining to chase display portion of active SOLISs exceeds the available memory, forcing the system to drop chase data that might be referenced by a viewer. It is undesirable because whenever the viewer references this data, the viewer s display becomes blank as the referenced data is no longer available. Data utility refers to the user s satisfaction with the quality of displayed data. An ST may reduce the size of incoming data by producing a lower resolution (quality) format. This data format might be perceived as undesirable by a user who may stop viewing it. The user s satisfaction is application specific and we assume a system administrator quantifies it by assigning a utility to each data format. A higher utility value reflects a better quality of service (a more satisfied user). We assume the device produced data has the highest utility. Inputs to DA-AdmCtrl include the amount of available memory, the alternative STs supported by the server and their inter-dependencies, and the characteristics of each ST such as its compression factor, anticipated service time, and utility of its output data. Given data formats, each format is represented as a node 2 At the time of this writing, one may purchase a ZT Desktop PC with 16 GB of memory and a 2 TB disk drive for less than $900. 5 and an edge represents an ST that consumes one data format to produce another. Thus, an inter-dependency is a directed acyclic graph consisting of nodes and edges annotated with meta-data. Figure 3 shows four inter-dependencies describing the average size of a data format (number in the node) and service time of an ST (value assigned to an edge). While the inter-dependencies of Figure 3 are simple, our proposed admission control supports arbitrarily complex inter-dependencies as long as they are trees, i.e., directed acyclic graphs with one root, ). DA-AdmCtrl must either admit or reject SOLIS requests such that it meets its configured objective using its available resources. The server starts buffering the chase data for a SOLIS as soon as it is admitted by the DA-AdmCtrl. The chase portion of a rejected SOLIS is not buffered and the request may proceed as a livestream. The decision to admit requests is trivial when the available memory exceeds the chase display requirements of the active SOLISs and their device produced data. The problem becomes interesting once the number of active SOLISs is such that a newly arrived SOLIS request exhausts the available memory. Now, DA-AdmCtrl must decide which STs to employ pro-actively to accommodate the incoming SOLIS. In essence, DA-AdmCtrl is solving a two dimensional bin packing problem. On one dimension, it strives to meet the memory requirements of the active SOLISs and STs used to compact them. On a second dimension, it solves how to schedule STs using the available CPU cores. We solve the problem using a two step heuristic. The first step identifies how many SOLISs are supported given a combination of (+ ) data formats. Each combination results in mixes of data for the identified data formats. A mix defines the number of SOLISs in each format within the + possible formats, +-,.. Each mix supports a fixed number of SOLISs and has a utility. Different mixes are stored in a sorted array, identifying the maximum number of SOLISs (/ ) supported by system resources (memory and cores). In the second step, DA-AdmCtrl uses this array to decide whether to admit or reject a new request. At any instance in time, DA-AdmCtrl is aware of the number of active SOLISs. If the maximum number (/ ) is reached and a new SOLIS request arrives, DA-AdmCtrl rejects this new request to prevent memory overflow for the existing SOLISs. Otherwise, it computes the new number of SOLISs in the system and looks up the table to identify the mix that supports this new number. It proceeds to schedule CPU resources to realize the identified mix. Similarly, when a SOLIS leaves the system, DA-AdmCtrl decrements the number of SOLISs in the system and looks up the table to identify the most suitable mix. It may stop scheduled summarizations that are either not necessary or reduce the utility of data unnecessarily. Below, we elaborate on these two steps in turn. C.1 Step 1: Mix of STs The first step of the heuristic computes different mixes of + data formats. Each mix supports a fixed number of SOLISs and may offer a different utility. To simplify discussion and without loss of generality, we assume each SOLIS has a fixed chase display duration. Section C.1.1 extends this discussion to SOLISs 6 8 9 A B K O B B Figure 3: Example inter-dependencies: (a) Deep-Desc, (b)deep-asc, (c)shallow-desc, (d) Shallow-Asc. Numbers in each node denote the size of a data format per unit of time. Numbers next to an edge denote the service time of a summarization technique, chosen to highlight the tradeoffs associated with DA-AdmCtrl (see discussions of Figure 6). with varying values. The value of + dictates the number of data formats that DA-AdmCtrl may employ at an instance in time. It is an integer greater than or equal to zero and less than or equal to. If +-10 then DA-AdmCtrl must admit requests based on device produced data format and may not use an ST. If +.32 then DA-AdmCtrl may admit requests by using one of the data formats. If +465 then DA-AdmCtrl may admit requests by using a combination of either one or two (out of the data) formats. And when +47, DA-AdmCtrl may utilize all available data formats simultaneously. The number of STs used to generate a combination of + data formats is dependent on the inter-dependency Term 9;:= Definition Chase display duration. Number of cores, i.e., simultaneous summarizations. Number of cores to summarize data format Total available memory. Number of data formats. Device produced data format. BDC? An available data format E. ST F G A summarization technique. B Size of data format? in one time unit. H G B Time required to generate?, EI(J. Number of data formats used simultaneously, LNM K M Maximum number of admissible SOLISs. Table 1: List of terms and their definitions.. 7 e U k between the data formats. To illustrate, consider the Deep-Desc inter-dependency of Figure 3.a. When +PQ2, DA-AdmCtrl may utilize any one of these data formats to admit requests. To produce the most compact representation with average size of 1 KB, DA-AdmCtrl must utilize 3 STs and apply them in succession. With the Shallow-Desc inter-dependency (see Figure 3.c), DA-AdmCtrl may use 1 ST to produce the most compact representation. A combination is a set consisting of + data formats: RS, RT,..., RVU, RW YX[Z\),,..., ^], RW `_ With +ab0, the set only consists of and DA-AdmCtrl must use. With +dcd0, the number of possible combinations is e gf)h \i. Larger values of + increase the number of combinations. When +6j0, the number of admissible SOLISs is lnm poq where r is the size of available memory, is the size of device produced data in one time unit, and is the duration of chase display in the same time unit granularity. When +sa2, there are possible combinations, each set with one unique data format RW. Each combination has one mix consisting of one t value, the number of SOLISs supported by its corresponding data format. The exact value of t depends on the available memory, the summarization service time uwvyx, and the number of cores, see Equation 1. When +zc{2, each combination supports a set of admissible requests: ZVt , tv,..., where t\ is the number of SOLISs supported by its corresponding data format. Each set is named a mix and supports U gf tp admissible SOLISs. For example, with one of the inter-dependencies of Figure 3 and +b{5, a combination might be and. Assuming a system with 10,000 KB of memory configured with the granularity of time set to 1 second and =1 second, a mix of this combination might be Z 91, 90], supporting a total of 181 SOLISs. This mix
Search
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks