# GANA-VDC: Application-Aware with Bandwidth Guarantee in Cloud Datacenters
## 1 Introduction  
Cloud data centers and cloud services providers guarantee CPU, memory, and storage for tenant virtual machines. However, they fail to ensure cloud network bandwidth availability, preventing tenants from achieving predictable running application performance due to limited network-bandwidth availability. Applications are often deployed in a traditional data center, claiming specialized network topology and routing mechanism to achieve better performance and infrastructure expense reduction. Unfortunately, VDC suffers deficient performance from the one-size-fits-all routing scheme prevalent in data center networks. While modern protocols support multiple paths through schemes, such as Equal-Cost Multi-Path routing (ECMP) [1; 2], in which each path continues to be selected using the same optimizationmetric, higher requirement cloud tenants should retain the ability to self-define both their network topology and forwarding path according to application characteristics set in the cloud data center [3]. The authors of [4], devoted to controlling logic over cloud network functions, solved this issue by installing flowtable entries in physical switches; however, it fails to maintain scalability. Moreover, the shared nature of the network in the multi-tenant cloud data center implies network performances for VDC vary significantly. No internal traffic control mechanisms exist in popular cloud services providers, such as Amazon EC2 [5], Rackspace Cloud [6], and Microsoft Azure [7], not to mention the fine-grained traffic control mechanisms for the specific service type. Thus, the imperative exists to provide bandwidth guarantees for VDC under the premise of application-aware networking and the feasibility of fine-grained traffic control for tenants in cloud data centers, offering similar performance guarantees exhibited in the enterprise; therefore, the challenges for such scenario are considered below. **Tenants self-defined network scalability:** Recent research on cloud data center virtualization has made it possible to decouple the VN configuration from the underlying physical network fabrication where tenants can self-define VDC network topology [8; 9] and allocate arbitrary subnet address to the designated virtual machine (VM) with the full address space virtualization provided. Gateways realize access control among various subnets. However, self-defining packets forwarding rules in independent VDC, promoting application-aware networking, has failed to be implemented in popular cloud data centers. Even though software-defined network technology can be employed to implement network virtualization to achieve application-aware networking [10], it does not apply to the cloud environment due to its original, considerable services revealing a severe switch state maintenance scalability problem. Therefore, allowing tenants to embrace application-aware networking power in the cloud data center addresses an onerous existing challenge virtual data centers need to solve. **Better VNE schemes and VN to PN mapping:** A prerequisite for supporting bandwidth guarantee in cloud datacenter holds appropriately allocating bandwidth resource in the physical network among VDCs to meet sufficiently tenant's SLA demands. Such an approach can be divided into the following two parts: mapping virtual VDC machines to a physical node and mapping the virtual link to physical link. This is usually considered a multi-commodity flow problem, demonstrating an NP-hard single unsplittable source flow [11]. Through the years, several virtual network mapping heuristics have been proposed; in our research, we found the four most profound in cloud datacenter [12; 13; 14; 15]. To the best of our knowledge, virtual network mapping algorithms adopt serialized VM-centered VN to PN mapping patterns, requiring each VM to be first mapped to a suitable position to fulfill the given conditions. When allocating a VDC with thousands of VMs in cloud datacenter hosting over 100,000 computing nodes, which takes approximately 100s.