Scheduling On-Demand Broadcast Items

Transcription

1 Scheduling On-Demand Broadcast Items Miao Wang Advisor: Ilias Michalarias Freie Universität Berlin, Institute for Computer Science Abstract. The demand for various information delivery services has enormously increased over the past few years and data broadcast has become more and more popular because of its nearly infinite scalability. In a broadcast scenario the key consideration is the scheduling algorithm that determines the next data item to be delivered over the network. The goal is to find a well performing algorithm in terms of average and worstcase performance. To efficiently use data broadcast different scheduling algorithms need to be developed and evaluated according to different metrics and measures. The algorithms must meet criteria to minimize response time and decision overhead and provide good scalability and applicability. Key words: broadcast, on-demand, pull-based, scheduling algorithm, LDCF, RxW 1 Introduction Due to recent developments in telecommunications, data networks, and mobile computing the transferred bandwidth as well as the demand for various information delivery services has enormously increased over the past few years. The World Wide Web today provides a universal platform to distribute information around the world. But most web-based systems fail to meet high user demands under peak loads resulting in slow response or poor availability. The delivery by unicast performs poorly with a large client population because every data item must be transmitted individually, increasing load on the server and the network. A considerable number of researches have been done in the field of largescale data-dissemination to find more efficient methods for data delivery. Many of those relied on broadcasting, where one server delivers information to a large number of clients [1],[2],[3],[4],[5],[6],[7],[8]. Broadcast technology is very popular because one response can potentially satisfy many users and therefore highly scalable because it can support additional clients without the need for major changes in the infrastructure. Satellite, terrestrial and cable TV networks have the capabilities to establish a platform for digital data broadcast. The information messaging system in cellular

2 2 Scheduling On-Demand Broadcast Items phones or other mobile devices provide traffic information, volatile time-sensitive information such as stock prices and weather information as well as periodic news distribution. The television information retrieval service called teletext is another example of broadcast application. Broadcast delivery can either be push-based or pull-based. In a push-based environment the server does not receive any direct requests by its clients but schedules the data packages based on the statistics or profiles of the clients request pattern. On the other hand in a pull-based setting the server would receive all requests by its clients and transmits the data packages for certain clients according to a scheduling algorithm. A pull system can potentially achieve better performance than a push system but requires the cost of an extra return channel, resulting in suggestions for hybrid architectures [9],[10],[11]. In this paper, I will examine pull-based broadcast also known as on-demand broadcast, where the server delivers on the requests by one of its clients. The scheduling algorithm, that determines which data item will be delivered over the network next, is critical for the broadcast performance. The goal is to find a well performing algorithm in terms of average and worst-case performance. Furthermore the algorithm needs to scale well in terms of increasing client population, request arrival rates, database sizes and bandwidth. The scheduling has to be evaluated against responsiveness and robustness and the decision overhead should be minimized. Previous algorithms established in operating system design have failed to address one or more of these issues when used for broadcasting. This paper reviews several previous algorithms for broadcast scheduling as well as promising new suggestions. In Section 2, I will give background information about the used model and used metrics to measure individual and overall system performance. Then I will review few of the previous algorithms used for scheduling in Section 3. Afterwards in section 4, I describe and discuss related work that have introduced new algorithms specialized for broadcast scheduling. Finally, Section 5 will provide a conclusion. 2 Background 2.1 Model To visualize our broadcast setting, I will present a model as an example similar to the one in Figure 1. The environment consists of a large population of clients c i that use an uplink channel to make requests for a data item to one single server s. These requests are queued up at the server upon arrival. The server then determines the next data item to be scheduled and transmits it via the downlink channel as a broadcast. The clients monitor the broadcast to pull of the requested data item. You can almost pick any network system for both uplink and downlink channel like terrestrial, satellite or even phone line. In our model we assume that there is only one broadcast channel monitored by the clients and that the channel bandwidth is fully dedicated for the data broadcast. The effect of transmission errors is not taken into consideration, i.e.

3 Scheduling On-Demand Broadcast Items 3 Fig. 1. Example model for a broadcast environment every broadcasted item is received by the waiting clients. We further simplify the scheduling of data items which can be split into fixed-length pages, such as database or memory pages. 2.2 Metrics and Measures To evaluate the quality and performance of different scheduling algorithms, there is the measure of individual and overall average system performance. Both must be looked at collectively since a good algorithm for an individual case does not satisfy the large number of clients in the average. On the other hand overall average performance may favor the majority and adversely affect a few individuals. We will therefore look at different metrics and measures that have been introduced in recent works to evaluate different scheduling algorithms in a couple of dimensions. Response Time The response time of a request is typically used as an individual performance measure which is the time between the request submission and receipt of the response. The goal is to minimize the response time, since it also indicates the total time spent by a client actively listening to the channel. A longer response time would cause more power consumption for clients with limited battery supply. Stretch Recent work also took the stretch of a request into consideration which is defined to be the ratio of the response time of a request to its service time. The stretch translates more directly to user-perceived performance since it takes the service time of each request into account. Thus, longer requests are expected to

4 4 Scheduling On-Demand Broadcast Items be in the system longer than shorter ones. Minimizing both response time and stretch gives us a metric to improve system performance. However, it is hard and sometimes impossible to exactly determine the service time of a request. Decision Overhead The rationale for this metric is to have a key dimension to improve the responsiveness of an algorithm. A good scheduler shouldn t only deliver the data items in a short time frame but also have little decision overhead. Therefore the cost of making the decision which item to deliver next must be minimized to make the most of the given broadcast bandwidth. An algorithm that makes decisions slowly will stall the broadcast and waste bandwidth that could be used. Fairness Furthermore scheduling should be fair. The fairness is a rather abstract measure that ensures that no data item has to face starvation, i.e. wait for an indefinite time to be broadcasted because there are always data items that need to be broadcasted before. Thus, the worst-case wait time has also to be measured and ensured that unpopular data items do not suffer this fate. Scalability Another consideration is the scalability of scheduling algorithms that must be provided when the scheduling problem grows in the number of request arrival rates, data item sizes or broadcast rate. In any case the algorithm should handle the heavy traffic and still perform well enough and not be a bottleneck. 3 Related Work In this section we review a number of relevant pull-based scheduling algorithms proposed in previous work. Most of them have similarities with scheduling algorithms used in operating systems. Thus, there are well-known and easy to understand but also not always applicable for a broadcast setting. Later, we will introduce several newly proposed algorithms that perform better in a broadcast scenario. 3.1 Previous Algorithms FCFS The easiest scheduling algorithm is a simple queue where data items are scheduled in the order they arrived in. This First-Come-First-Served (FCFS) strategy is straight-forward and known to minimize the maximum response time. Similarly to a checkout line at the supermarket the data requests form a queue and wait until their turn to be processed. This is extremely fair because requests are ensured to get processed after a finite period and will not wait endlessly. Furthermore the decision overhead is constant, there is no expensive calculation that needs to be done. However, FCFS performs extremely poor in a broadcast

5 Scheduling On-Demand Broadcast Items 5 setting because it only takes the requested time into account and never considers the difference of access frequencies of various data items. Hence, it is not considered a good algorithm for broadcast scheduling [2]. MRF / MRFL The Most-Request-First (MRF) and the Most-Request-First- Lowest (MRFL) scheduling algorithm take the number of requests as a measure to determine the next broadcasted page [12],[13]. In MRF the data item with the largest number of requests is always delivered, so that popular items are favored which are most likely to be requested again. But that is not fair: data items with only a few requests will come up short and maybe wait endlessly to be processed. The MRFL scheme is similar to MRF, but it breaks ties in favor of pages with the lowest request access probability and is slightly better. LWF The Longest-Wait-First (LWF) algorithm chooses the data item with the largest total waiting time (the sum of the total time that all pending requests for that item have been waiting for). LWF takes both the number of requests and the waiting time into account and usually outperforms FCFS and MRF. It therefore reduces the problem of endless waiting items but does not resolve it. Also, it is very expensive to implement and mostly replaced by RxW which will be described later [2]. SSTF If the service time of a request can be estimated or even exactly calculated, the Shortest-Service-Time-First (SSTF) scheduling algorithm can be used which broadcasts the data item with the shortest service time. This has the advantage that short requests can be processed really fast, but the scheduling is not fair since large jobs may be always excluded by many short jobs that arrive frequently often [2]. LTSF The Longest-Total-Stretch-First (LTSF) algorithm is based on the stretch metric. It tries to calculate the stretch value for each request and broadcasts the item with the largest total current stretch value (the sum of the current stretches of all pending requests for the item). If the stretch value can be approximated adequately, this is an algorithm that also performs well and fairly for data items with variable data sizes [2]. EDF In [14], the authors propose requests associated with a deadline. With Earliest-Deadline-First (EDF) the requests with the nearest deadline is processed in favor of the others. Although the EDF strategy is guaranteed to find a feasible scheduling in a point-to-point case, it does not necessarily in a broadcast case. The problem is that processing large jobs may cause many other jobs to miss their deadline. A way to prevent this is to allow the preemption of processed requests which leads to a better stretch, but it can be easily shown that it will also lead to starvation with endless waiting time [2].

6 6 Scheduling On-Demand Broadcast Items 4 Newly proposed algorithms We see that the previous algorithms each lack a little in order to be efficiently used in a broadcast setting. Hence, many authors have come up with new solutions for the scheduling problem which will be outlined and discussed here. LDCF (Longest Delay Cost First) The Longest Delay Cost First scheduling algorithm was proposed in 2003 [7] which key consideration is the costs for each broadcast. It also takes request failures into account, if the server could not broadcast an item within a response time limit (RTL). LDCF tries to minimize a weighted sum of the access time cost elapsed between request and response (C AT ), the tuning time cost a user has to spend actively listening to the channel (C T T ) and the cost of handling failed requests (C F ) because the request could not be satisfied in a certain time period. For each scheduling decision the data item with the largest cost is calculated and selected to broadcast. The idea to minimize the tuning time and the number of failed requests for clients is promising for low-energy devices with limited battery supply. The average cost evaluated for the LDCF algorithm in several experiments is little lower than for LWF or MRF. But LDCF is much more complex and complicated and requires more scheduling decision overhead to calculate the costs for each request. Fig. 2. LDCF performance compared to various pervious algorithms RxW In [3] a new broadcast scheduling algorithm called RxW is presented which provides excellent performance across a various range of scenarios. To combine the benefits of MRF and FCFS, the RxW algorithm calculates the

7 Scheduling On-Demand Broadcast Items 7 product of R (the number of outstanding requests for that page) and W (the time of the oldest outstanding request for that page). It therefore maintains two values with each service queue and always chooses to broadcast the page with the maximal RxW-value. The decision overhead is O(n) since the algorithm has to go through each data item and calculate its RxW-value. This could be too time consuming and wasting downstream bandwidth. Figure 3 shows an example: For each R-W-pair the RxW-value is calculated. The item d has the highest RxW-value which is 600. Thus d will be broadcasted in the next cycle. Fig. 3. RxW algoritm RxW.α To reduce the search overhead of RxW an approximate version RxW.α has been developed where α is a tunable parameter in percent that controls the desired level of approximation. The idea is to prune the search space since the chosen data item will most likely be one with high R-value or high W-value. The algorithm works as follows: the server maintains two sorted lists: the R-list based on the number of outstanding requests and the W-list based on the waiting time of the oldest request. The search starts at the top of the R-list, were the RxW value for that data item is computed and recorded as the current maximum. Thereafter the top of the W-list is examined and its RxW value compared to the current maximum. The algorithm then keeps alternating between the two lists and stops when it encounters an item with a RxW value greater than or equal to α times the threshold. The threshold is the running average of the RxW values that have been broadcasted so far. After each broadcast the threshold is updated and the data item removed from the service queue. Thus, the α value regulates the tradeoff between schedule quality and decision overhead. A smaller α lowers the decision overhead, whereas a greater α tends to exacter decisions. Figure 4 shows an example based on the one shown in Figure 3: The threshold is set to 500 and α is 0.9 (RxW.90). Thus we look until we will find a item with RxW-value higher than = 450. The RxW-value for item c with the highest R-value is calculated first as 440. It does not satisfy our criteria, so the next RxW-value for item b with highest W-value is calculated as 540, which meets our criteria. Item b will be broadcasted and our threshold updated.

8 8 Scheduling On-Demand Broadcast Items Fig. 4. RxW.α algoritm Aksoy has demonstrated the performance, scalability, and robustness of the RxW and RxW.α variants through an extensive set of performance experiments and analysis. They have shown that RxW performs significantly better than previous algorithms (LWF, FCFS) and provides an efficient use of broadcast resources [3]. The tradeoff between request rate and average waiting time indicate a inherent scalability of broadcast delivery and makes it an ideal technology for large-scale data-dissemination. Furthermore RxW is easily integrable with opportunistic scheduling techniques such as cache-residence and server cache management such as love/hate-hints as well as prefetching [1]. Fig. 5. RxW.α algoritm

9 Scheduling On-Demand Broadcast Items 9 Multi-item and Transactional Requests So far we have only considered broadcast decisions at the data item level where we only consider the case of single-item requests. But in reality there is often the setting where clients attempt to download multiple data items with one request in a transactional way. For example database clients often access multiple items to complete a read transaction; similarly web clients try to access HTML documents with all its embedded objects. For such a given landscape it is more favorable to consider the set of transactions on the data items. In [5] an on-demand algorithm is outlined for transactional settings. Fig. 6. Transaction data request table In Figure 6 a transaction data request table is illustrated. A transaction t 1 requests d 1, d 2 and d 7. Equally the data item d 3 is required by transactions t 2, t 3 and t 4. A scheduling decision on data item level, like MRF, would have a broadcast schedule like d 1, d 2, d 3, d 4, d 5, d 6, and d 7. This is very unfortunate for transaction t 1 who has to wait until the 7th broadcast tick. Not only does this increase the waiting time but the longer the waiting time the more probable it is to have a inconsistent state when values are updated in between. In a transactional setting the scheduling decision is not made after each broadcast but at periodic intervals referred to as broadcast cycles. One scheduling decision makes a decision for the entire broadcast cycle to come. In a initial step the temperature of transactions is calculated. The temperature T emp i of a transaction t i gives the average measure of the number of hot data items (frequently accessed data items) in a transaction. It is calculated as the sum of the number of requests for each data item in the transaction divided by the number of data items in the transaction. In our example the temperature T emp 1 of transaction t 1 would be ( )/3 = 10/3. Afterwards, all transactions are sorted in descending order according to their T emp i x W i value where W i is the wait time of the transaction t i. Then data items are chosen to be broadcasted from the sorted transaction list until the maximum capacity to broadcast in a broadcast cycle is reached. Furthermore indexing and filtering can be used

10 10 Scheduling On-Demand Broadcast Items to further improve the scheduling. Thus, transactions will have shorter waiting times to be completed than in a scheduling based on single-item requests. Fig. 7. LDCF performance compared to various previous algorithms In a transactional context this algorithm has certain advantages over previous algorithms like FCFS, MRF or RxW because it drastically improves the average transaction wait time. But the decision overhead is time consuming and dependent on arriving transactions. In a setting where transactions are not that time critical RxW is sufficient to use. 5 Conclusion In this paper we have introduced the problem of on-demand broadcast scheduling in a pull-based model. The scheduling algorithm that determines the next data item to be delivered over the network is the key consideration of broadcast scheduling. We have shown several previous algorithms for broadcast scheduling

11 Scheduling On-Demand Broadcast Items 11 that are easy to understand and implement but do not perform as well as modern algorithms in certain metrics and measures. We have described some newly proposed algorithms that perform promisingly well. The LDCF algorithm does not only try to minimize the access time but also the tuning time and the number of failed requests for clients. This is very promising for low-energy devices but the scheduling decision is rather complicated on the other hand. The RxW algorithm shows excellent performance across a range of scenarios and is fairly easy to understand. The idea is to choose the data item with the highest product of R (the number of outstanding requests for that page) and W (the time of the oldest outstanding request for that page). Therefore RxW maintains two queues holding R- and W-values. In this basic variant RxW has to go through both lists linearly and has a decision overhead of O(n). The RxW.α is a little improvement over the basic RxW. The goal is to prune the search space with a tunable parameter α that controls the desired level of approximation. Since either a value with high R- or W-value is most likely to be selected, those are the ones that are first checked alternatively for broadcast. If a RxW-value is found which is higher than α times a threshold, this item is broadcasted and the threshold updated. Different approaches have to be made in a transactional context. Prabhu and Kumar have introduced an algorithm for multi-item and transactional requests to lower the transactional waiting time. The algorithm does not work on data item level but on a transactional level and chooses the data item for the transaction with the highest temperature (average measure of the number of frequently accessed data items). This algorithm can prove very useful in a transactional context where transactional waiting time is critical. Table 1 gives an overview of the discussed scheduling algorithms in this paper and their evaluation towards different measures. Response Stretch Decision Fairness Scalability Time Overhead FCFS MRF LWF SSTF LTSF EDF LDCF RxW Trans Table 1. Conclusion of introduced algorithms

12 12 Scheduling On-Demand Broadcast Items As data broadcast becomes more and more popular because of its nearly infinite scalability, different scheduling algorithms need to be developed. We have introduced a few modern ones that have advantages in certain fields. The RxW algorithm is a generic method which performs well in many scenarios. All methods have made the implicit assumption that all of the data items to be disseminated are readily available at the server when they are scheduled. However, the items may reside in secondary or tertiary storage and require a certain service time to be fetched. This can destroy the performance of the broadcast scheduling heuristics. In order to prevent this, methods like opportunistic scheduling techniques, server cache management and prefetching can be used which all work great with RxW [1]. References 1. Demet Aksoy, Michael J. Franklin, and Stanley B. Zdonik. Data staging for ondemand broadcast. pages , Swamp Acharya and S. Mutlutkrislulan. Scheduling on demand broadcasts new metrics and algorithms. ACM Press, pages 43 54, Demet Aksoy and Michael Franklin. Rxw: A scheduling approach for large-scale on-demand data broadcast. IEEE/ACM Transactions on Networking, Volume 7, No. 6: , N. Kamiyama. Broadcast scheduling for large contents distribution with guaranteed response time. ICC 06. IEEE International Conference on Communications, 2006, 4: , Nitin Prabhu and Vijay Kumar. Data scheduling for multi-item and transactional requests in on-demand broadcast. pages 48 56, Majid Raissi-Dehkordi and John S. Baras. Broadcast scheduling in information delivery systems. Global Telecommunications Conference, GLOBECOM 02. IEEE, 3: , Weiwei Sun, Weibin Shi, Bole Shi, and Yijun Yu. A cost-efficient scheduling algorithm of on-demand broadcasts. Wirel. Netw., 9(3): , Chi-Jiun Su and Leandros Tassiulas. Broadcast scheduling for information distribution. pages , J. W. Wong and M. H. Ammar. Analysis of broadcast delivery in a videotex system. IEEE Trans. Comput., 34(9): , Swarup Acharya, Michael Franklin, and Stanley Zdonik. Balancing push and pull for data broadcast. pages , Konstantinos Stathatos, Nick Roussopoulos, and John S. Baras. Adaptive data broadcast in hybrid networks. pages , J. W. Wong. Broadcast delivery. IEEE, 76(12), M. H. Ammar H. D. Dykeman and J. W. Wong. Scheduling algorithms for videotex systems under broadcast delivery. First International Workshop on Satellite-based Information Services, O. Gonzalez J. Fernandez P. Xuan, S. Sen and K. Ramamritham. Broadcast ondemand: Efficiently and timely disseminating of data in mobile environment. IEEE RTAS, 1997.