## 5 Dynamic Bandwidth Allocation
### Dynamic Bandwidth Allocation Adjustment
Every period consists of query time of the receiving rate of active flows and calculation time of the suitable sending rate of each source VM as well as the short thread sleep time. To predict this upward trend, we set the throttle rate +20% of the regulated rate to allow ramp up, and we collect the continuous 10 flow rates. If these rates are in ascending order or some of them are equal to the throttled rate, then the lent out bandwidth will be reclaimed. As Figure 14 describes, we trace the stipulated bandwidth and the actual sending rate of each flow. At t0 time, we increase the rate of flow4 up to 150 Mbps. At t1 time, the upward trend of flow4 is detected, and then the rate of flow4 recovers to its original allocated bandwidth (300 Mbps). Besides, the bandwidth of flow1 and flow2 changes from 270 to 145 Mbps, respectively. At t2 time, flow4 is deemed as bounded, we evenly lend the redundant bandwidth of the flow4 to only the flow1 and flow2, as flow3 is bounded. Hence, we overlap the bandwidth of flow1 and flow2 with their corresponding traffic rate, respectively. Regarding flow3 and flow4, to reserve the possibility of taking back the lent bandwidth, they are allocated 20% more than the actual traffic rate each. Figure 14: The rapid bandwidth recovery when increasing flow4. Figure 7:0 The detailed variation of flow rates in [t2, t3]. We magnify the interval between t0 and t2 as Figure 15 shows, it costs 710 ms in total between flow4 increases to 50 Mbps and flow4 is bounded. In the former 180 ms, we detect the upward trend of flow4 rate. Obviously, this upward period is much shorter than the time of flow bounded assertion. In the latter 530 ms, flow4 becomes bounded. This time, the cost is much more than the ideal 300 ms, because it includes part of increasing time of flow4 as well. ## 8 Conclusions

With the development of scale economy, more and more distributed applications are forced to co-exist with each other in shared infrastructure. The best-effort resource sharing mechanism of the network can cause unfair allocation of network bandwidth among VDCs. To address this problem, NXT-Freedom is an attempt made by us to achieve the enforcement of VDC-based fair bandwidth guarantees, while providing work-conserving allocations with minimum bandwidth demands at the same time. The minimum bandwidth demands abstracted by the SCG model in the VN are fine-grain than those of the hose model, further advancing the total network utilization. NXT-Freedom can be employed by the cloud service providers to achieve fair network bandwidth across tenants in a flexible and efficient manner, which can prevent accidental or malicious traffic interference. Through the classification of the VN type, to some degree, we can reduce the CPU overhead of NXT-Freedom, which makes NXT-Freedom more practical. Conceptualization, [PERSON] and [PERSON]; methodology, [PERSON]; software, [PERSON]; validation, [PERSON], [PERSON] and [PERSON]; formal analysis, [PERSON]; writing-original draft preparation, [PERSON]; writing-review and editing, [PERSON]. All authors have read and agreed to the published version of the manuscript. This work was supported by the National Key Research and Development Program of China under Grant 2018 YFB0204005. The authors declare no conflict of interest. ## References

* (1) [PERSON]; [PERSON]; [PERSON]; [PERSON]; [PERSON]; [PERSON]; [PERSON] Survey of techniques and architectures for designing energy-efficient data centers. _IEEE Syst. J._**2016**, _10_, 507-519. [CrossRef]
* (2) [PERSON]; [PERSON]; [PERSON]; [PERSON] Nxt-Freedom: Considering VDC-based Fairness in Enforcing Bandwidth Guarantees in Cloud Datacenter. In Proceedings of the 2018 IEEE International Conference on Networking, Architecture and Storage (NAS), Chongqing, China, 11-14 October 2018; pp. 1-6. Figure 7:1 Detailed rapid bandwidth recovery in [t0, t2]. * [PERSON] et al. (2018) [PERSON]; [PERSON]; [PERSON]; [PERSON] Nxt-Max: for supporting VDC-based maximum redundant bandwidth allocation in cloud datacenter. _Clust. Comput._**2018**, _22_, 12567-12580.