TCP Bandwidth Allocation for Virtual Networks

Transcription

1 TCP Bandwidth Allocation for Virtual Networks Shuoh-Ren Tsai Department of Computer and Communication Engineering, National Kaohsiung First University of Science and Technology, Taiwan Tzu-Chien Lin Department of Computer and Communication Engineering, National Kaohsiung First University of Science and Technology, Taiwan Abstract TCP occupies more than 90 percent of internet traffics. In the virtual networks of data centers, the TCP bandwidth allocation becomes crucial, due to multiple virtual concurrent TCP connections. And new TCP versions proposed for data centers is still in progress. In data centers, high throughput and low Round Trip Time (RTT) are expected in TCP connections. It is not easy to fulfill both the required QoS and the minimum network resource consumption in TCP, due to the Additive Increase Multiple Decrease (AIMD) of TCP. Token Bucket Algorithm has been widely adopted for bandwidth control. And we analyzed and found the minimum bucket sizes for TCP New Reno and Data Center TCP (DCTCP). In this study, we observed the behaviors of DCTCP and TCP cooperated with Token Bucket Algorithm. We obtained the analytical models for Token Bucket, Explicit Congestion Notification (ECN), and those two TCP versions. We used both Mininet (emulation) and Network Simulator (NS) to conduct the verification of analytical models. The results of emulation and simulation are quite close to our analytical models. flexibility and scalability of network resources. Software- Defined Networking (SDN) follows up the trend, and both Openflow and vswitch are supported by major networking vendors [1] [] [3]. It is a new era of networking. Another possible way to solve the traffic issue is the congestion control in TCP. New Reno is the most widely used protocol in TCP congestion control, but it is not suitable for high volume of traffics, such as data center. Stanford University and Microsoft propose Data Center TCP (DCTCP) for the congestion control of the internal data transfer in data centers [4]. Both the Token Bucket Algorithm and DCTCP are investigated in this paper to validate the performance of their cooperation in a data center. First of all, we briefly explain why DCTCP is applicable to a data center and then describes the relevant mechanisms. Secondly, we have a quantitative analysis of the relationship between the token rate and the related token bucket size of the token bucket algorithm. Our analytical results are validated using Mininet and NS. Keywords - vswitch; Token Bucket; TCP; Data Center; ECN; Mininet 1. INTRODUCTION With the popularity of smart mobile devices and the speed increase of wireless network access, Internet has become part of daily lives. Also, more people watch videos on Youtube, listen to music on Grooveshark, and use twitter/facebook to share the latest information with others. The innovation of network technology creates a new era of emerging industries, such as network virtualization, content delivery network, and data center management. It is a challenge to manage a cloud with QoS guarantee for a variety of network services. As network speed grows behind the user demands, network intends to the degradation of QoS, which is usually caused by packet loss, due to limited bandwidth or finite buffer size. In order to overcome the packet loss drawback, network administrators adopt the Token Bucket Algorithm to limit the transmission rate of individual users. This algorithm provides a simple, effective way to control traffic flows. Virtual networking has attracted much attentions, and it has been popularly adopted in data centers. Virtual networks are to provide networking for virtual machines, and it increases Figure 1. A typical network architecture in a data center Furthermore, with the Token bucket algorithm, we compare TCP with DCTCP, in term of the throughput. Finally, we summarized the relationship of token bucket size and buffer size which can achieve the desired rate.. DATA CENTER TCP In the TCP protocol, the most popular congestion-avoidance scheme is the Reno algorithm, which adjusts the window size to one half, but not starting with 1 like Tahoe, when the network is congested. TCP New Reno was proposed to overcome the drawback of Reno, when there are multiple packet losses within the same round-trip time. When more than one packet are lost

2 simultaneously (within a RTT), Reno behaves like Tahoe, which adjust the window size from 1. New Reno modifies Reno s fast recovery step by distinguishing full ACK (FA) from partial ACK (PA). As the sender receives a PA ACK from the receiver, it means there is another packet loss. The sender re-transmits the next lost packet and wait for ACK packets, until it receives the FA ACK, which means there is no packet loss. The Reno scheme is effective in congestion relief for the general users in the Internet. However, it does not perform well in data centers. Figure 1 shows a typical network architecture in a data center, where a number of servers are installed and may compete in the use of the shared network bandwidth. Where α represents the degree of network congestion, is a weight value, preset to 0.065, and F is the portion of the number of packets with ECN tags marked. () Finally, the sender adjusts the window size by the following rule: 1 / (3) Here we realize why DCTCP would be more suitable than Reno as a better transport mechanism for data centers. When a network congestion occurs, Reno always reduces the window size to one half, while DCTCP may adjust the window with a size smaller than 1/. Figure depicts the window sizes adjusted by Reno and DCTCP respectively. 3. TOKEN BUCKET ALGORITHM ( Reno ( DCTCP Figure. Window size with the same throughput Accordingly, a higher probability of network congestion results. In order to maintain network stability and to guarantee high flow rates, Stanford University and Microsoft jointly proposed Data Center TCP (DCTCP) to improve the efficiency of TCP within a data center [4]. And we briefly revisit highlights of DCTCP in this section [4]. One of the advantages of DCTCP is that when a network congestion occurs, contention window size is adjusted in accordance with the degree of congestion, not always adjusted to 1/ as in Reno. In DCTCP, a threshold value K is determined as an indication that a network congestion occurs when the number of packets in the buffer is greater than K. Then, Random Early Detection will be adopted with a marked function activated with ECN tags in the packets which arrive after threshold K is reached. DCTCP adjusts the window size as follows: 1 (1) 3.1 OVERVIEW The Token Bucket Algorithm is widely used for network traffic control mechanism. Three parameters of the algorithm are token rate (r), token bucket size (B), and queue length. Figure 3 depicts their relationship. Here are the basic operations of the Token Bucket Algorithm described as follows: 1) As the token rate is r, every 1/r seconds a token is generated and then it is put into the token bucket. ) Token bucket can store up to B tokens. When the token bucket is full and a new token is added, the new token are discarded. 3) When a packet comes in and there are enough tokens in token bucket, the transmission of the packet is allowed, and the corresponding number of tokens will be removed. 4) If there are not enough tokens in the bucket for an incoming packet the packet is put into the queue, and it waits to be transmitted until the bucket is filled with enough tokens. The Token Bucket Algorithm limits the transmission rate, but the occurrence of an unexpected traffic is also allowed, depending on availability of tokens. Figure 3. Token Bucket Algorithm 3. Pre-Validation of Simulation To validate our Mininet models of Token Bucket Algorithm, which are consistent with the models published by other researchers [5]. We configured the same topology in the Mininet,

3 and obtained the results of the token bucket size for different token rates. We compared our results with those ones in [5] using NS and OMNET++, as shown in Figure 4 and Figure Analysis The study in [5] indicates that if we do not have a token bucket large enough, the resulting throughput is not be close to the token rate, because there are not enough tokens to allow the increase of the window size. Therefore, it is important to determine the token bucket size for better performance. As shown in Figure 6, area B(1) occurs when the current window size is smaller than the token rate, where the current packet arrival rate is lower than the token generating rate. When the packet arrival rate is higher than the token generating rate, the average throughput approaches the token rate. Area B() denotes that the state of congestion avoidance is ensured. Both areas can be calculated based on the following equations: (pkts) Figure 4. Bucket size versus TCP goodput in 1 Mbit/s: Source: [5] Fig. 3, Our results using Mininet Figure 6. Token bucket size in Reno B B / 3 (5) Then, we can calculate the area of B: B B 1 B (RTT time) (4) 3 (6) The above analysis is for a single TCP flow. If there are multiple TCP flows within the same bucket size, further analysis is required. In fact, regardless of a single flow or multiple flows, the amount of transferred packets are the same. Therefore, we just calculate the area of whole area and divide it by N, if the number of flows is N. We can get a new value of, and we can calculate the token bucket size for multiple TCP flows. Total area The new ( ) can be derived as follows: (7) Figure 5. Bucket size versus TCP goodput in 5 Mbit/s: Source: [5] Fig. 3, Our results using Mininet (8)

4 Beside the token bucket size in Reno, we are interested in the token bucket size for DCTCP. We use the same approach to calculate token bucket size in DCTCP. Figure 7 shows the window size by DCTCP. Figure 7. Window size in DCTCP (Source: [4] Fig. 11) (pkts) 1 1 (RTT time) Figure 8. Token bucket size in DCTCP In [4] and [7], we adopted the equation for : 1 / (9) Where is the critical window size at which the queue size reaches K, and 1 is a bottleneck (token rate). When current queue size reaches K, the window size is adjusted from 1 to 1 1 / D. And in [4] and [7], when α is small, this can be simplified as α /, if α /, then D B B (13) (14) B() is reduced by half, because within half of RTT, the sender receives marked packets and adjusts the window size. We find an equation is to determine the value of K [4][7], which is 1 /7 (15) B is set to the value based on equation (14). And K is suggested in [4] and [7] to achieve the maximum throughput (queue is never in starvation). If B is not larger than K, then we reduces K to less than B (B > K). Otherwise (if B < K), ECN could never functions, and the protocol performs like TCP New Reno, but not DCTCP. Also, although K does not follows equation (15), which is suggested in [4] and [7], the throughput is not far away from the best. In order to verify the above analysis, we use Mininet and NS in several simulations. Figure 9 and Figure 10 show the simulation results, which are quite close to theoretical ones. Our formulas (equation (6) and (14)) can accurately estimate token bucket size. 1 1 (10) We can compute W 1 1 α : (11) Then the token bucket size can be calculated. (see Figure 8): B 1 1 D/ 1 (1) Figure 9. Token bucket size simulation with TCP: Single, Multiple

5 Figure 10. Token bucket size simulation with DCTCP: Single, Multiple Figure 1. Token bucket size compare with TCP and DCTCP in single flow: throughput, token bucket size Figure 11. Experimental environment in Mininet 3.4 Token Bucket Schemes with TCP and DCTCP To investigate further, we performed simulations in Mininet. Our experimental topology is configured using Mininet in Figure 11. From the simulation results in Figure 1 and Figure 13, we observe that in both single TCP flow and multiple TCP flows, DCTCP uses less buffer to achieve the same throughput, which is quite close to token rate. This confirms that DCTCP outperforms in data centers. Also, we can have appropriate token bucket size for different token rate ( throughput) as shown in Table 1.

6 Figure 13. Token bucket size compare with TCP and DCTCP in multiple flows: throughput, token bucket size TABLE I. RESULT OF TOKEN BUCKET SIZE WITH MULTIPLE FLOWS ON TCP, DCTCP TCP N=1 Token rate Token bucket size (kbit) Throughput (Mbit/s) (Mbit/s) Theoretical Mininet TCP N= DCTCP N= DCTCP N= CONCLUSIONS We investigated Token Bucket congestion control mechanisms for New Reno and DCTCP, and we demonstrated that DCTCP is more suitable as a transport mechanism for data centers. Secondly, we have taken into consideration at the cooperation of token rate and token bucket size. The appropriate size of token bucket can be determined based on token rate, i.e. almost throughput. The threshold of ECN queue, K, is adjusted a little to be the same as token bucket size, and throughput is still close to token rate. REFERENCES [1] Kannan Govindarajan, Kong Chee Meng, Hong Ong, Wong Ming Tat, Sridhar Sivanand, Low Swee Leong, Realizing the Quality of Service (QoS) in Software-Defined Networking (SDN) based Cloud infrastructure, Proceedings of the nd International Conference on Information and Communication Technology (ICoICT), pp , May 014. [] N. Parvez, A. Mahanti, and C. Williamson. An analytic throughput model for TCP NewReno, Proceedings of the IEEE/ACM Trans. Networking, pp , Apr 009. [3] Open vswitch. [Online]. Available: [4] M. Alizadeh, A. Greenberg, D.A. Maltz, J. Padhye, P. Patel, B. Prabhakar, S. Sengupta, and M. Sridharan, Data center tcp (dctcp), Proceedings of the ACM SIGCOMM 010 conference on SIGCOMM, pp , Oct 010. [5] Ronald van Haalen, Richa Malhotra, Improving TCP performance with bufferless token bucket policing: A TCP friendly policer, Proceedings of the 15th IEEE Workshop on Local and Metropolitan Area Networks, pp. 7-77, Jun 007. [6] Adrian Lara, Anisha Kolasani, Byrav Ramamurthy, Network Innovation using OpenFlow: A Survey, Proceedings of the IEEE Communications Surveys and Tutorials, vol. 16, no. 1, pp , Aug 013. [7] M. Alizadeh, A. Javanmard, B. Prabhakar, Analysis of DCTCP: Stability, Convergence, and Fairness, Proceedings of the SIGMETRICS 011, pp , Jun 011. [8] Md. Faizul Bari, Raouf Boutaba, Rafael Esteves, Lisandro Zambenedetti Granville, Maxim Podlesny, Md. Golam Rabbani, Qi Zhang, and Mohamed Faten Zhani, Data Center Network Virtualization: A Survey, Proceedings of the IEEE Communications Surveys and Tutorials, vol. 15, no., pp , May 013. [9] Purnima Murali Mohan, Dinil Mon Divakaran, Mohan Gurusamy, Performance Study of TCP Flows with QoS-supported OpenFlow in Data Center Networks, Proceedings of the 19th IEEE International Conference on Networks (ICON), pp. 1-6, Dec 013. [10] S. Sahu, P. Nain, D. Towsley, C. Diot, V. Firoiu, On Achievable Service Differentiation with Token Bucket Marking for TCP, Proceedings of the ACM SIGMETRICS 000, Santa Clara, CA, pp. 3-33, June 000. [11] ONF: Open Networking Foundation. [Online]. Available: [1] Mininet: An Instant Virtual Network on your Laptop (or other PC). [Online].Available: