Thursday, October 3, 2019
Optimizing Cloud Resources Implementation of IPTV Service
Optimizing Cloud Resources Implementation of IPTV Service Optimizing Cloud Resources Implementation of IPTV service delivery through Virtualization MOHAMMAD ISMAIL Abstract- The Internet Protocol Television is a system over which Internet television services are delivered using the networking and architecture methods of the Internet Protocol Suite through a packet-switched network infrastructure, e.g., the Internet and broadband Internet access networks, rather of being delivered over traditional radio frequency broadcast, satellite signal, and cable television (CATV) formats. Implementation of IPTV Virtualization is of practical concern in numerous applications such as detecting an IPTV service delivery failure. The intrusion detection is determined as a mechanism for an IPTV service delivery over virtualization to detect the existence of inappropriate, incorrect, or anomalous moving attackers In this paper, we ruminate this issue according to inhomogeneous IPTV service delivery models. Furthermore, we ruminate two sensing detection models single-sensing detection and multiple-sensing detection we want to lower a providers cost of real-time IP TV services over a virtualized IPTV architecture and over intelligent timeshifting of service delivery, We define a extrapolated framework for computing the amount of resources needed to support multiple services, without missing the deadline for any service. We construct the problem as an optimization formulation that uses a generic cost function. Our simulation results show the benfits of multiple sensor inhomogeneous WSN IPTV service delivery through virtualization. We also show that there are attarctive open problems in designing mechanisms that allow time-shifting of load in such environments. I. Introduction Now a days the demand for Internet-based applications grows around the world, Internet Protocol Television (IPTV) has been very popular. The recent advances in communication and computer technology, television has gone over many advances over the years. Now a days IP based video delivery became more popular (IPTV). demands placed upon the service providerââ¬â¢s resources have dramatically increased. Service providers typically provision for the high demands of each service across the subscriber population. However, provisioning for high demands leaves resources under employ at all other periods. This is particularly evident with Instant Channel Change (ICC) requests in IPTV. Our goal is to take favor of the difference in workloads of the different IPTV services to better utilize the deployed servers. In IPTV, Live TV is typically multicast from servers using IP Multicast, with one group per TV channel. Video-on- Demand (VoD) is also supported by the service provider, with each req uest being served by a server using a unicast stream. For each channel change, the user has to join the multicast group associated with the channel, and wait for enough data to be buffered before the video is displayed; this can take some time. As a result, there have been many attempts to support instant channel change by mitigating the user perceived channel switching latency [1], [7]. In our virtualized environment, ICC is typically managed by a set of VMs while other VMs would be created to handle VoD requests. With the ability to spawn VMs quickly [1], we believe that we can shift servers (VMs) from VoD to handle the ICC demand in a matter of a few seconds. This requires being able to predict the ICC bursts which we believe can be predicted from historic information. Our goal is to find the number of servers that are needed at each time instant by minimizing a cost function while at the same time satisfying all the deadlines associated with these services. To achieve this, we i dentify the sever-capacity region formed by servers at each time instant such that all the arriving requests meet their deadlines. We show that forà any server tuple with integer entries inside the servercapacity region, an earliest deadline first (EDF) strategy can be used to serve all requests without missing their deadlines. This is an extension of previous result where the number of servers is fixed [2]. Thus, well known concave programming techniques without integer constraints can be used to solve the problem [3]. Finally, for a maximum cost function, we seek to minimize the maximum number of servers used over the entire period. II. RELATED WORK There are mainly three threads of related work, namely cloud computing, scheduling with deadline constraints, and optimization. Cloud computing has recently changed the landscape of Internet based computing, whereby a shared pool of configurable computing resources (networks, servers, storage) can be rapidly provisioned and released to support multiple services within the same infrastructure [7]. In preliminary work on this topic [4], we analyzed the maximum number of servers that are needed to service jobs with a strict deadline contraint. We also assume non-causal information (i.e., all deadlines are known a priori) of the jobs arriving at each instant. In this [5], considers the advancing scenario, this approach only requires a server complex that is sized to meet the requirements of the ICC load, which has no deadline flexibility, and we can almost completely mask the need for any additional servers for dealing with the VoD load. With the typical ICC implemented on current IPTV s ystems, the content is delivered at an accelerated rate using a unicast stream from the server [6], [7]. There have been multiple efforts in the past to analytically estimate the resource requirements for serving arriving requests which have a delay constraint. These have been studied especially in the context of voice, including delivering VoIP packets, and have generally assumed the arrival process is Poisson [8]. For a concave minimization with linear constraints, the solution is one of the corner points of the polytope formed by the linear constraints. III. Improved Cloud Data Utilization for IPTV Transmission Internet Protocol-based video delivery is increasing in popularity with the result that its resource requirements are continuously growing. It is estimated that by the year 2017 video traffic will account 69% of the total consumerââ¬â¢s Internet traffic. Content and service providers typically configure their resources such that they can handle peak demands of each service they provide across the subscriber population. The solution presented takes advantage of the temporal differences in the demands from these IPTV workloads to better utilize the servers that were deployed to support these services. While VoD is delivered via unicast, Live TV is delivered over multicast to reduce bandwidth demands. However, to support Instant Channel Change (ICC) in Live TV, service providers send a unicast stream for that channel for a short period of time to keep a good quality of experience. If a number of users change their channels around the same period of time, this produces a large burst l oad on the server that has to support the corresponding number of users. Compared to the ICC workload which is very bursty and has a large peak to average ratio, VoD has a relatively steady load and imposes a relatively lax delay requirement. By multiplexing across these services, the resource requirements for supporting the combined set of services can be reduced. Two services that have workloads which differ significantly over time can be combined on the same virtualized platform. This allows for scaling of the number of resources according to each serviceââ¬â¢s current workloads. It is, however, possible that the peak workload of different services may overlap. Under such scenarios, the benefit of a virtualized infrastructure diminishes, unless there is an opportunity to time shift one of the services in anticipation of the other serviceââ¬â¢s requirements to avoid having to deliver both services at the same time instant. In general, the cloud service provider strives to optimize the cost for all time instants, not necessarily just reducing the peak server load. Cost Function We investigate linear, convex, and concave functions With convex functions, the cost increases slowly initially and subsequently grows faster. For concave functions, the cost increases quickly initially and then flattens out, indicating a point of diminishing unit costs (e.g., slab or tiered pricing). Minimizing a convex cost function results in averaging the number of servers (i.e., the tendency is to service requests equally throughout their deadlines so as to smooth out the requirements of the number of servers needed to serve all the reques ts). Minimizing a concave cost function results in finding the extremal points away from the maximum to reduce cost. This may result in the system holding back the requests until just prior to their deadline and serving them in a burst, to get the benefit of a lower unit cost because of the concave cost function (e.g., slab pricing). The concave optimization problem is thus optimally solved by finding boundary points in the server-capacity region of the solution space. Fig1. IPTV Architecture. the potential of utilizing virtualization to support multiple services like Video On Demand (VoD) and Live broadcast TV (LiveTV). We explore how we can carefully configure the cloud infrastructure in real time toà sustain the large scale bandwidth and computation intensive IPTV applications (e.g. LiveTV instant channel changes (ICC) and VoD requests). In IPTV, there is both a steady state and transient traffic demand [2]. Transient bandwidth demand for LiveTV comes from clients switching channels. This transient and highly bursty traffic demand can be significant in terms of both bandwidth and server I/O capacity. The challenge is that we currently have huge server farms for serving individual applications that have to be scaled as the number of users increases. In this paper, we focus on dedicated servers for LiveTV ICC and VoD. Our intent is to study how to efficiently minimize the number of servers required by using virtualization within a cloud infrastructure to replace dedicat ed application servers. Since there is storage at set top boxes (STBs), by properly speeding up the delivery prior to the burst ICC load, the delay constraints for the VoD can be relaxed for a period of time. The opportunity is to explore how these services may coexist on the same server complex. We cause one service (VoD) to reduce its resource requirements temporarily to help support a sudden influx of requests from another (LiveTV ICC) service. IV.Impact of Cost Function on Server Requirements We investigate linear, convex, and concave functions. With convex functions, the cost increases slowly initially and subsequently grows faster. For concave functions, the cost increases quickly initially and then flattens out, indicating a point of diminishing unit costs (e.g., slab or tiered pricing). Minimizing a convex cost function results in averaging the number of servers (i.e., the tendency is to service requests equally throughout their deadlines so as to smooth out the requirements of the number of servers needed to serve all the requests). Minimizing a concave cost function results in finding the extremal points away from the maximum (as shown in the example below) to reduce cost. This may result in the system holding back the requests until just prior to their deadline and serving them in a burst, to get the benefit of a lower unit cost because of the concave cost function (e.g., slab pricing). The concave optimization problem is thus optimally solved by finding boundary p oints in the server-capacity region of the solution space. The linear cost represents the total number of servers used. The minimum number of total servers needed is the total number of incoming requests. The optimal strategy is not unique. Any strategy that serves all the requests while meeting the deadline and using a total number of servers equal to the number of service requests is optimal. One strategy for meeting this cost is to set to serve all requests as they arrive. The optimal cost associated with this cost function does not depend on the deadline assigned to each service class. V. Evolution We provided an analytic framework that computes the optimal amount of resource (i.e., number of servers at different times) for accommodating multiple services with different deadlines. The initial theoretical framework depends on non-causal information regarding the arrival times and deadlines for each chunk of a requested content. We demonstrate two optimization approaches namely, postponing and advancing VoD delivery. Alternatively, VoD requests can also be advanced after the initial movie request without incurring any startup delays (i.e., subsequent chunks of the movie can be advanced before their playout deadlines). We set up a series of experiments to see the effect of varying firstly, the ICC durations and secondly, the VoD delay tolerance on the total number of concurrent streams needed to accommodate the combined workload. In figures diurnal VoD time series (in blue) and a ICC time series (in red). For a given VoD Delay nâⰠ¥0, we use two services, one with delay 0 and o ne with delay . For each incoming VoDà movie request of length L, a request is made of second service in each of the L consecutive time-slots. Further, each ICC burst creates a request for the first service. Thus, given the requests of the two services, gives the number of concurrent streams that are necessary and sufficient to serve all the incoming requests Fig2: Maximum Cost: Maximum number of Concurrent Sessions. A movie request is made up of different chunk deadlines. For each chunk, we associate a service class i. Specifically the i th chunk of any movie is designated a service class with a corresponding deadline of i-1. For a requested movie, we enlist a request made of L service classes (service classes 1 to L ), where L is the movie length. A LiveTV ICC request corresponds to a service class 1 request for 15 consecutive seconds as in the postponement case. For an operational trace as shown in Fig. 2, with advancing, a maximum of 24955 concurrent streams can accommodate both LiveTV and VoD requests. With only LiveTV, the total number of concurrent streams needed is 24942. VoD requests can be essentially serviced with just an additional 13 concurrent streams. VI. Conclusion We presented the construction of an efficient PDP scheme for distributed cloud storage. Based on homomorphism verifiable response and hash index hierarchy, we have proposed a cooperative PDP scheme to support dynamic scalability on multiple storage servers. IPTV service providers can leverage a virtualized cloud infrastructure by intelligently timeshifting load to better utilize deployed resources while still meeting the strict time deadlines for each individual service. We used LiveTV ICC and VoD as examples of IPTV services that can run on a shared virtualized infrastructure. Our paper first provided a generalized framework for computing the resources required to support multiple services with deadlines. We formulated the problem as an optimization problem and computed the number of servers required based on a generic cost function. We considered multiple forms for the cost function of the server complex (e.g., min-max, convex and concave) and solved for the optimal number of serve rs required to support these services without missing any deadlines. We provide an analysis that computes the minimum number of servers needed to accommodate a combination of IPTV services, namely VoD session and Live TV instant channel change bursts. By anticipating the LiveTV ICC bursts that occur every half hour we can speed up delivery of VoD content by prefilling the set top box buffer. This helps us to dynamically reposition the VoD servers for accommodating the LiveTV bursts that typically last for 15à to 30 seconds at most. Our results show that anticipating and thereby delaying VoD requests gives significant resource savings.à References [1] H. A. Lagar-Cavilla, J. A.Whitney, A. Scannell, R. B. P. Patchin,à S.M. Rumble, E. de Lara, M. Brudno, andM. Satyanarayanan,à ââ¬Å"SnowFlock: Virtual machine cloning as a first class cloudà primitive,â⬠ACM Trans. Comput. Syst. (TOCS), 2011. [2] J. A. Stankovic,M. Spuri, K. Ramamritham, and G. C. Buttazzo,à Deadline Scheduling for Real-Time Systems: Edf and Relatedà Algorithm. Norwell, MA, USA: Kluwer, 1998. [3] N. V. Thoai andH. Tuy, ââ¬Å"Convergent algorithms for minimizing aà concave function,â⬠Math. Oper. Res., vol. 5, 1980. [4] V. Aggarwal, X. Chen, V. Gopalakrishnan, R. Jana, K. K.à Ramakrishnan, and V. Vaishampayan, ââ¬Å"Exploiting virtualization forà delivering cloud-based IPTV services,â⬠in Proc. IEEE Conf.à Computer Communications Workshops (INFOCOM WKSHPS), Apr.à 2011. [5] V. Aggarwal, V. Gopalakrishnan, R. Jana, K. K. Ramakrishnan, andà V. Vaishampayan, ââ¬Å"Optimizing cloud resources for delivering IPTVà services through virtualization,â⬠in Proc. IEEE Int. Conf.à Communication Systems and Networks (COMSNETS), Jan. 2012. [6] D. Banodkar, K. K. Ramakrishnan, S. Kalyanaraman, A. Gerber, andà O. Spatscheck, ââ¬Å"Multicast instant channel change in IPTV system,â⬠à Proc. IEEE COMSWARE, Jan. 2008. [7] Microsoft TV: IPTV Edition. [Online]. Available:à http://www.microsoft. com/tv/IPTVEdition.mspx. [8] G. Ramamurthy and B. Sengupta, ââ¬Å"Delay analysis of a packet voiceà multiplexer by the Queue,â⬠IEEE Trans. Commun., pp. 1107ââ¬â1114,à Jul. 1991. [9] H. Tuy, ââ¬Å"Concave programming under linear constraints,â⬠Sovietà Math, vol. 5, pp. 1437ââ¬â1440, 1964. [10] S. Sergeev, ââ¬Å"Algorithms to solve some problems of concaveà programming with linear constraints,â⬠Autom. Remote Control, vol. [11] A. Dan, D. Sitaram, and P. Shahabuddin, ââ¬Å"Scheduling Policies for anà On-Demand Video Server with Batching,â⬠in Proc. of ACM Multimedia,à San Francisco, CA, October 1994, pp. 15ââ¬â23. [12] A. J. Stankovic, M. Spuri, K. Ramamritham, and G. Buttazzo, ââ¬Å"Deadlineà Scheduling for Real-Time Systems EDF and Related Algorithms,â⬠1998,à the Springer International Series in Engineering and Computer Science.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.