# Bouncer: A Resource-Aware Admission Control Scheme for Cloud Services
## 4 System Design
### Workload Distribution and Overload Avoidance Policy for Workload-Admission Control  
Bouncer considers a scenario similar to [23] where the submitted tasks (or the service requests) are represented by a row vector \(\mathbf{t}=[\text{t}_{1},\,\text{t}_{2},\,\text{t}_{3},\,\ldots,\,\text{t}_{n}]\). The resources required by these tasks is represented by a row vector \(\mathbf{r}=[\text{r}_{1},\,\text{r}_{2},\,\text{r}_{3},\,\ldots,\,\text{r}_{n}]\). We mapped these two-row vectors together in such a way that every individual member of row vector \(\mathbf{r}\) represents the resource consumption for its respective element in row vector \(\mathbf{t}\). To ensure overload avoidance, we need to add a requirement whereby the system cannot accept requests that would lead it to exceed the available compute nodes of Bouncer. Therefore, for \(\mathbf{T}\) number of total available compute nodes. \[t\cdot r=\sum_{i=1}^{n}t_{c}r_{c}\leq T \tag{1}\]  
where \(t_{c}\) and \(r_{c}\) represent the cumulative tasks and resources utilization, respectively. Our analysis goal is to develop a function where the chances of rejecting requests are minimal. Therefore, total response time \(R_{t}\) for a cluster \(Q\) can be derived as an objective function given by Equation (2). \[R_{t}\left(Q\right)=W_{t}\left(Q_{\textit{inprocess}}\right)+W_{t}(Q_{\textit{ waiting}})\leq W_{\textit{threshold}} \tag{2}\]  
The performed analysis works as a gateway for the submitted requests. It streams and segregates requests by considering their threshold capacity (see Figure 2). A detailed commentary on the variables used in Equations (1) and (2) is presented in Table 1. The performed analysis improves the queuing and resource provisioning constraints in two ways:  
* By mapping the requests along with their resource usage, which provides a clear description of all the services and their occupied resources by using Equation (1). * By analyzing \(R_{t}\) for individual requests and ensuring that the results do not exceed \(W_{\textit{threshold}}\), which helps to ensure that the deadline violations of the requests can be minimized by using Equation (2). In order to preserve the QoS levels, the workload distribution and overload avoidance policy assign applications to hosts with the required resource capacity. Here, we assume that the resources required by an individual application are a composite of the memory, CPU, and storage resources. We, therefore, consider every incoming application requirement on the basis of these three aspects. The admission-control policy thus looks up VMs with sufficient available resources to entertain the incoming resource demands. For this, we consider a queue \"_\"_\" containing a number of applications, where each application has its own set of resource demands. We then consider another queue \"_\"_\", containing available VMs. In order to address the utility maximization concerns for queue structures [5], we ensure that every incoming application is provided with its required resource demands. Bouncer ensures that applications are admitted into the system only once it is ensured that enough resources exist to process them. The working of the workload distribution and overload avoidance policy for workload-admission is outlined in Figure 2. Upon joining a network, our system assigns these applications to their potential VMs. This gives way to a free queued structure for the workload-admission system, where if resources are not contentious, applications can easily enter into a network. However, if the required resource requirements exceed the available VM resource threshold capacity, applications are queued and the process is repeated until all the applications in \"_\"_\" are either admitted to the VMs or is dropped beforehand. In cloud services, taking a decision on the basis of existing utilization of network links is critically important. This not only facilitates the incoming services but also facilitates in accommodating futuristic network demands.