TCP performance evaluation over multihomed networks

Transcription

1 TCP performance evaluation over multihomed networks Rafaa Tahar HANA Research Group University of Manouba, Tunisia Rafik Braham Prince Research Unit University of Sousse, Tunisia Amine Dhraief HANA Research Group University of Manouba, Tunisia Abdelfettah Belghith HANA Research Group University of Manouba, Tunisia Abstract Current Internet nodes can be considered as multihomed end-hosts as they are equipped with several wireless interfaces, each one related with a distinct access technology. The Transport Control Protocol (TCP) is considered as the cornerstone of Internet. However, current TCP implementations do not take into account the multihoming aspect of the current Internet nodes. In this paper we target to quantify the impact of the multhoming nature of the end-hosts on TCP. For this purpose, we design a novel multi-interfaced mobile node in the OMNeT++ network simulator. Our model relies on Layer 2 virtualization approach in order to implement an abstraction of the available wireless interfaces towards the upper-layers protocols. Obtained results shows that Layer 2 virtualization mitigate some of the TCP misbehavior on a multihomed environment. Index Terms TCP, multihoming, OMNeT++, Layer 2 virtualization I. INTRODUCTION According to the 2011 statistics of the International Telecommunication Union (ITU) 1, 33 individuals are using the Internet per 100 inhabitants in the world, 16 of them have and active mobile-broadband subscriptions. In other words, in 2011, the ITU estimates to one billion the number of mobilebroadband Internet users in the world. Current Internet users are using smart-phones and laptop equipped with different wireless access technologies such as Wi-Fi, 3G or even 4G/LTE. Each wireless interface is generally attached to a specific Internet Service Provider (ISP). Such terminals are called multihomed hosts. Furthermore, current TCP/IP stack has been designed for fixed hosts having a single interface. Thus, current TCP/IP stack does not take advantage form the intrinsic multihomed nature of the current Internet hosts. In a multihomed environment, TCP is subject to receive out-oforder segments, as end-hosts might be reachable through several interfaces. Theses out-of-order segments are interpreted by the TCP state machine as congestion phenomenon in the network. In fact, upon receiving out-of-order segments, TCP immediately sends a duplicated acknowledgment. The TCP sink receiving this duplicated ACK will assume that it is due 1 to a packet loss, as a consequence of a congestion, and reduces its congestion windows. This scenario clearly illustrates the misbehavior of TCP in a multihomed environment. Current TCP implementations are not able to differentiate between duplicated ACK due to a congestion episode and packets losses form duplicated ACK due to the multi-interface nature of the end-host and the reception of out-of-order segments. In this paper we aim to evaluate the performance of the current TCP implementation in a multihomed environment through extensive simulations tests. For this purpose, we propose to design a novel multi-interfaced mobile node in the eventdriven network simulator OMNet++. We also target to evaluate the impact of distribution TCP traffic among the available wireless interfaces on the overall network throughput. It is important to mention that, for backward compatibility with existing applications, we do not target to design a novel multihoming enabled transport protocol. This paper is organized as follows. In the second section we present the multihoming concepts and its impact on the TCP protocol. In the third section, we highlight our contribution and the key features of our new mobile node architecture. In the four section we evaluate the performance TCP on a multihomed environment in order to quantify the impact of the multihoming on the TCP protocol. The last section concludes this paper and presents some ideas on our future work. II. RELATED WORKS In the following, firstly, we define the multihoming concept and detail its benefits. Then, we highlight TCP limitations in a multihomed environment. Finally, we present some of the recently proposed solutions which mitigate TCP limitations in a multihomed environment. A. Multihoming The ITU estimated in 2011 to one billion the number of mobile-broadband Internet users in the world. These users rely on end-hosts equipped with several wireless network devices using different access technologies such as LTE, Wi-Fi and Bluetooth. Such end-hosts are considered as multihomed

2 mobile hosts [6]. Furthermore, several corporates consider their Internet access as a strategical resource as they depend on it to run their daily business. They usually have distinct Internet Service Providers (ISPs) subscriptions in order to be always connected to the Internet. Such end-sites are considered as multihomed endsites. An entity (network/end-host) is usually considered as multihomed if it has at least two IP addresses obtained from distinct ISPs [2]. With the forthcoming version of the IP protocol, IPv6, we can have different multihoming configurations: a multihoming entity may have a single connection/interface with a multihomed upstream provider, or several connections/interfaces associated with different providers. Multihoming improves network performance in term of delay, available bandwidth and resilience against failure. Akella et al. [1] demonstrated that a multihoming network connected to two ISPs has its average performance improved by 25% as the number of concurrent paths increases and lower delays are found among the available paths. B. TCP Limitations in a multihomed environment In 1974, Vinton Cerf et al. [4] proposed the first Internetworking protocol, the Transmission Control Protocol (TCP). Thereupon, TCP has become the cornerstone of ARPANET and then Internet. When TCP was first designed, end hosts were single-interfaced and were connected to a single-homed end-site. Regular TCP does not take into account multi-path environment nor multi-interfaced nodes. As a consequence, using regular TCP in a multihomed environment might affect overall TCP performances. TCP assumes that packets losses are mainly due to the congestion in the network. Therefore, TCP considers packet losses as hints of congestion in the path between the source and the sink. TCP detects packet losses either by a timeout of the TCP Retransmission Timer or by the reception of duplicated acknoweldgment. After the reception of three duplicated acknowledgments, TCP halves its congestion window. TCP congestion windows is a similar to the flow control sliding window mechanism. It limits the number of bytes that may be exchanged between a sender and a receiver and hence prevents the overload of the path between them. Multihomed environment increase the likehood of receiving out-of-order TCP segments. Upon receiving an out-of-order segment, TCP immediately sends a duplicated acknowledgment. As explained earlier, three duplicated acknowledgments results into the reduction of the TCP congestion window. In such scenario, TCP erroneously concludes that duplicated acknowledgments are due to packet losses and enters in a congestion avoidance phase. This is a typical use case of the inaccuracy of current TCP implement in a multihomed environment. C. Multihoming-enabled transport protocols Several proposals in the literature enable the multihoming support in the transport layer such as Multihomed TCP, TCP- MH, DCCP, SCTP and Multi-path TCP. Multihomed TCP [9], TCP-MH [13] and Multi-path TCP [8] add a multihoming support to TCP while SCTP and DCCP are new transport protocols. Multihomed TCP uses a context identifier instead of IP addresses and ports to identify a connection. TCP-MH modifies the SYN segment to contain all the available addresses and implements primitives (MH-Add,MH-Delete) to modify the address currently in use. Multi-path TCP is a newly standardized IETF protocol [7] that allows a regular TCP flow to spread among different paths. The Datagram Congestion Control Protocol (DCCP) did not originally support multihoming. In fact, multihoming is added as an extension [12] that provides a extension adds primitive to transfer the established connection from on address to another. SCTP [14] provides a native multihoming support by associating one session with multiple IP addresses and thus with multiple paths. One path is considered as primary and the others are backups. III. REGULAR VS. SPLIT TCP As stated previously, internet users are equipped nowdays with several wireless networks devices running different access technologies. These multi wireless devices could be modelised by multi-interface mobile nodes. These devices could be homogeneous or heterogeneous i.e running same or differents access technologies. In this paper we will focus solely on homogenous wireless technologies namely the IEEE x technologie. Thereby in this section we will present our approach based on the key feature of Layer 2 Virtualization. A. Multi-Interface mobile node architecture Several discrete-event network simulators (NS-2, J-SIM, OMNeT++) use the same mobile node model as presented by Figure 1. This model has the following building blocks : a Physical layer, a MAC sub-layer which implements the protocol state machine, a Management sub-layer (LLC), a set of complementary modules which models wireless communications specific aspects such as : mobility, propagation models, cross-layering features,etc. and upper layers modules (IP, Transport, Applications). A mobile node can be considered as multihomed end-host if it has configured several global IP addresses. A sub-case of multihomed mobile node is a mobile node equipped with distinct wireless interfaces, each interface having its own IP address. Multi-interfaced mobile node is intrinsically different form multi-channel mobile node, even if both of them use different orthogonal wireless channels. While a multi-interfaced mobile node can simultaneously use all the available orthogonal channels, in a multi-channel mobile node we use a single channel at a time. Furthermore, in a multi-interfaced mobile node since every interface is tuned to a given channel, MAC sub-layer management is more flexible and easy as it does not require routines for channel scanning

3 and switching. Finally, in multi-interfaced mobile node, the LLC sub-layer management is more complex, since additional procedures should be implemented to efficiently handle the multi-interface, such as : multiple MAC address management and virtualization. The classical mobile node model presented by Figure 1 does not allow us to simulate multihomed mobile node. In our previous works [15], [3], we have quantitatively Fig. 1: Classic Mobile Node Architecture compared multi-interfaced mobile nodes and multi-channel mobile nodes. These studies led us to propose a novel mobile node architecture, as shown in Figure 2. Our new model relay on three building blocks: (i) a set of Physical and MAC sub-layer BLock (PM-Block) which implementing a MAC sub-layer state machine with its corresponding physical module, (ii) a Virtual MAC Layer (VML) and (iii) a cross-layer which is a modular collection of agent, mobility model, propagation model,... Fig. 2: Multihomed Mobile Node Architecture B. The Virtual MAC Layer The VML implements an abstraction of the available wireless interfaces (NICs) to the upper layers (IP and TCP). The VML virtualizes the set of the available interfaces into a single virtual interface having a single MAC and physical layer. Thus, Upper layer protocols are not aware of the presence of the multiple interfaces and do not implement any specific multihoming routine. Finally, the VML is responsible of the incoming/outgoing traffic distribution among the available interfaces. To achieve the traffic distribution, the VML implements layer 2 scheduling techniques. The choice of the scheduling policy for traffic distribution is one of the most relevant issues encountered at this layer. Since in this paper we solely focus on TCP traffic, we consider two TCP traffic scheduling policies: Regular TCP and Split TCP. The Regular TCP scheduling does not differentiates between DATA and signaling segment in the selection of the next PM- Block; whereas, in the Split TCP scheduling, the PM-Block selection is driven by the type of TCP segment to be sent. In Regular TCP scheduling policy we investigate two scheduling algorithms, the Round Robin Regular-RR and the Random Uniform Regular-RU algorithms, to dictate the selection of the PM-Block. By Regular-RR we mean that we select the next PM-Block in a circular order. In a Regular-RU, the selection of the the next PM-Block is given by a random uniform distribution function. In the Split TCP scheduling policy, we differentiate TCP DATA segments from signaling segments. Indeed the first PM- Block is exclusively dedicated for TCP signaling segments; whereas the remaining PM-Blocks are dedicated to TCP DATA segment. Similarly to the Regular TCP policy, we investigate the Round Robin Split-RR and the Random Uniform Split- RU algorithms, to dictate the next PM-Block selection (for TCP DATA segment only). In the next section, we evaluate the performance of both Regular TCP and Split TCP in a multihomed environment. IV. PERFORMANCE EVLUATION In the following section, we present a performance evaluation Regular TCP and Split TCP in a multihomed environment using the OMNet++ network simulator. A. Metrics We focus on three metrics: the throughput, the collision ratio and the DupAck ratio. These metrics are defined as follows: Throughput : The quantity of information per time unit delivered to all destination stations. That is : T hroughput = nbframes f ramesize simduration where nbframes denotes the number of frames received successfully by all destination stations, framesize denotes the size of an exchanged frame in bit and simduration denotes the simulation duration in seconds. Collision Ratio : The number of the overall collisions which occurred on all the used interfaces by the total number of the exchanged Frames. That is : CollisionRatio= nbcollision nbframes where nbcollision denotes the number of frame implied in a collision. DupAck Ratio : The percentage of duplicated TCP acknowledgment exceeding the DUPTHRESH (3 times) occurred by (1) (2)

4 the total number of duplicated TCP ACK. That is : DupAck exceeding DUPTHRESH Ratio= nbdupackthresh nbdupack (3) where nbdupackthresh denotes the duplicated TCP acknowledgment that exceeds the DupThresh which is equal to 3 and nbdupack denotes the duplicated TCP acknowledgment. B. Simulation Scenario Table. I shows the simulation scenario parameters. The TABLE I: General simulation parameters Parameter Value PYH and MAC bitrate 11 Mbps Number of channels 6 +(1 signaling channel for Split TCP) Application pattern FTP (Server and Client) Number of TCP Flows 6 flows : Each STA and host contains a single FTP Server and a single FTP Client TCP MSS 1460 Bytes TCP ACK 40 Bytes TCP and IP headers 40 Bytes MAC header 34 Bytes Simulation Time 50 sec Figure 3 shows our simulation scenario. We considerate a T F = PHY h +DIFS+CW mean +DATA[F]+SIFS+ACK+(2 δ) (4) Where : PHY h is the Physical header length. CW mean is the mean value of the contention window size. DATA[F]= bitrate F 8, bitrate is the bit rate of the channel and F is the length in byte of the Frame F. ACK is the time duration of IEEE ACK. δ is the propagation delay. For the Regular TCP policy, DATA and signaling traffic are sent on the same channel. Since a TCP exchange consists of transmitting a TCP DATA Segment and receiving a TCP ACK. The mean occupation channel time necessary for this exchange according to 4 is given by : T E = 2 [PHY h + DIFS+CW mean + SIFS+ACK+(2 δ)] +DATA[TCP Seg ]+DATA[TCP ACK ] (5) For the Split TCP policy, the first channel is dedicated for signaling traffic and the other channels are dedicated for DATA traffic. The mean occupation channel time necessary for signaling traffic according to 4 is given by : T S = PHY h + DIFS+CW mean + DATA[TCP ACK ] +SIFS+ACK+(2 δ)] and the mean occupation channel time necessary for DATA traffic according to 4 is given by : (6) T D = PHY h + DIFS+CW mean + DATA[TCP Seg ] +SIFS+ACK+(2 δ)] Let us define the channel efficiency ρ as the quantity DATA[F] T F. The theoretical throughput of a channel c is given by : (7) Fig. 3: Simulation scenario wireless segment formed by 3 mobile stations and an Access Point having multiple interfaces. Even if our new mobile node architecture allow mobile nodes to have heterogeneous configurations especially different number of interfaces, for simplification reasons, we choose to use a unique mobile node configuration per simulation run. The Access point ensures wired bridging to a router that is connected to 3 hosts. Each mobile station and host is running 1 FTP server and 1 FTP client which give us 6 TCP flows. C. Theoretical throughput According to IEEE standard [10], [11], [5], in an empty BSS, the mean time duration of a Frame F noted T F is given by : T h(c)=ρ bitrate(c) (8) When we use multiple interface i.e multiple channel the theoretical overall throughput T h Reg for Regular TCP policy according to 8 is given by : T h Reg =(ρ Reg bitrate(c)) n (9) and the theoretical overall throughput T h Spt for Split TCP policy according to 8 is given by : Th Spt =[ρ Sig bitrate(c)]+[(ρ Data bitrate(c)) n] (10) where n denotes the number of available channel, ρ Reg as the quantity (DATA[TCP Seg]+DATA[TCP Ack ]) T E, ρ Sig as the quantity and ρ Data as the quantity DATA[TCP Seg] T D. DATA[TCP Ack ] T S

5 TABLE II: General IEEE b Parameters Parameter Value PHY h 192 µs SIFS 10 µs DIFS 50 µs CW mean 310 µs ACK 112 µs δ 2 µs TCP and IP headers 40 Bytes MAC header 34 Bytes Table II presents general IEEE b parameters. By replacing numerical values of Table II in equations 9 and 10 we obtain the theoretical throughput for Regular and Split policies, for a single DATA channel which is given by Table III and for multiple DATA channel which is given by Table IV : Figure 4 shows the theoretical throughput for the two TABLE III: Channel efficiency and theoretical throughput Parameter Value ρ Reg ρ Sig ρ Data Th Reg Mbps Th Spl Mbps Fig. 5: Mean Throughput We notice that for the two policies, Round Robin algorithm outperforms the Random Uniform one. This is explained by the Collision Ratio (see Figure 6). Figure 6 shows that TABLE IV: Theoretical throughput for multiple DATA channel Number of Regular Split Data channel Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps Mbps scheduling policies Regular and Split. Fig. 4: Regular vs. Split Analytic Throughput D. Results and interpretation Figure 5 shows the throughput vs. the number of the available interfaces for the Regular and Split policies with the two scheduling algorithms namely Round Robin and Random Uniform. Fig. 6: Collision Ratio collision ratio obtained for Random Uniform algorithm is grater than the one obtained for Round Robin algorithm. Recall that collision is due to the fact that two or more mobile node select the same interface to send a frame at the same contention period, we call this interface synchronization. With Random Uniform the interface synchronization occurs more that in Round Robin algorithm. Indeed if an interface synchronization occurs with the Round Robin algorithm, the first mobile node that wins the contention will not be reached for the next frame but for Random Uniform the mobile station that gains the contention may have an interface synchronization for the next frame since interface selection is done in a random manner. In Figure 6, we also notice that Split policy outperforms the Regular one for a number of interfaces less or equal to 3. For a number of interface greater than 3, we observe a landing for the Split policy. This is due to the signaling channel saturation. Signaling channel saturation reduces the number of TCP Segment sent therefore the overall throughput. At TCP level, Regular and Split policies have an impact on duplicated TCP ACK. Indeed since Frames are sent on

6 different channels TCP segments sequence will not be maintained and/or TCP ACK will be delayed by signaling channel saturation : this will result in duplicated TCP ACK (see Figure 7). Fig. 7: Collision Ratio Figure 7 shows that Round Robin algorithm is always better than Random Uniform algorithm. V. CONCLUSION TCP was firstly designed in 1974 for fixed nodes equipped with single interface. Current TCP implementations do not take into account multihomed environment in general, and more specifically, multi-interfaced mobile nodes. In fact several scenario illustrates the misbehavior of TCP in a multihomed environment. In this paper, we evaluated the performance of the current TCP implementation in a multihomed environment through simulations tests. We designed for this purpose a novel multi-interfaced mobile node in the network simulator OMNeT++. Our new multi-interfaced mobile nodes relied on Layer 2 virtualization in order to present an abstraction of the available wireless interfaces towords the upperlayers protocols. Conducted simulations showed that Layer 2 virtualization realizes a significant enhancement the overall network throughput in multihomed environments. Further investigations are also underway on two issues : the first one is intelligent scheduling policies. By intelligent we mean using Physical and/or MAC informations to dictate PM-Block selection such as sending on the early contentionfree PM-Block (the first one on which we have send or receive wlan-ack). The second issue is using bufferization technique within the VML. This technique aims to re-sequence TCP Segment in order to omit duplicated TCP acknowledgment which will certainly have a positive impact on TCP congestion. [3] Abdelfettah Belghith, Rafaa Tahar, and Rafik Braham. Enhancing qos parameters using an ieee multi-interface based wireless distribution system (mi-wds). The Global Information Infrastructure Symposium (IEEE-GIIS 2009), Hammamet, Tunisia, [4] V. Cerf, Y. Dalal, and C. Sunshine. Specification of Internet Transmission Control Program. RFC 675, December [5] Amine Dhraief, Abdelfattah Belghith, Nicolas Montavont, Jean-Marie Bonnin, and Mohamed Kassab. Ns2 based simulation framework to evaluate the performance of wireless distribution systems. In Proceedings of the 2007 spring simulaiton multiconference - Volume 1, SpringSim 07, pages , San Diego, CA, USA, Society for Computer Simulation International. [6] Amine Dhraief, Issam Mabrouki, and Abdelfattah Belghith. A serviceoriented framework for mobility and multihoming support. In Electrotechnical Conference (MELECON), th IEEE Mediterranean, pages , march [7] A. Ford, C. Raiciu, M. Handley, S. Barre, and J. Iyengar. Architectural Guidelines for Multipath TCP Development. RFC 6182 (Informational), March [8] Huaizhong Han, Srinivas Shakkottai, C. V. Hollot, R. Srikant, and Don Towsley. Multi-path tcp: a joint congestion control and routing scheme to exploit path diversity in the internet. IEEE/ACM Trans. Netw., 14(6): , December [9] C. Huitema. Multi-homed tcp. draft-huitema-multi-homed-0 (work in progress), May [10] IEEE. Ieee : Part 11 : Wireless lan medium access control mac and physical layer phy specifications, [11] IEEE. Ieee b : Part 11 : Wireless lan medium access control mac and physical layer phy specifications : Higher-speed physical layer extension in the 2.4 ghz band, [12] Eddie Kohler. Datagram congestion control protocol mobility and multihoming. draft-kohler-dccp-mobility-01 (work in progress), January [13] Arifumi Matsumoto, Masahiro Kozuka, and Kenji Fujikawa. Tcp multihome options. draft-arifumi-tcp-mh-00 (work in progress), October [14] R. Stewart. Stream Control Transmission Protocol. RFC 4960 (Proposed Standard), September Updated by RFCs 6096, [15] Rafaa Tahar, Abdelfettah Belghith, and Rafik Braham. Performance evaluation of ieee multi-interface based wireless distribution system mi-wds. The 7 th ACS/IEEE International Conference on Computer Systems and applications (AICCSA09), Rabat, Morocco, REFERENCES [1] Aditya Akella, Bruce Maggs, Srinivasan Seshan, and Anees Shaikh. On the performance benefits of multihoming route control. IEEE/ACM Trans. Netw., 16(1):91 104, [2] Amine Dhraief and Abdelfettah Belghith. Multihoming support in the internet: A state of the art. In International Conference on Models of Information and Communication Systems (MICS 2010), Rabat, Morocco, 2010.