Portal de Periódicos da CAPES

Network traffic control for multi‐homed end‐hosts via SDN

2020; Institution of Engineering and Technology; Volume: 14; Issue: 19 Linguagem: Inglês

10.1049/iet-com.2020.0335

1751-8636

Anees Al‐Najjar, Furqan Hameed Khan, Marius Portmann,

Network Traffic and Congestion Control

IET CommunicationsVolume 14, Issue 19 p. 3312-3323 Research ArticleFree Access Network traffic control for multi-homed end-hosts via SDN Anees Al-Najjar, Corresponding Author Anees Al-Najjar alnajjaram@ornl.gov Oak Ridge National Laboratory, Oak Ridge, TN, USASearch for more papers by this authorFurqan Hameed Khan, Furqan Hameed Khan School of ITEE, The University of Queensland, St Lucia, Brisbane, QLD, 4072 AustraliaSearch for more papers by this authorMarius Portmann, Marius Portmann School of ITEE, The University of Queensland, St Lucia, Brisbane, QLD, 4072 AustraliaSearch for more papers by this author Anees Al-Najjar, Corresponding Author Anees Al-Najjar alnajjaram@ornl.gov Oak Ridge National Laboratory, Oak Ridge, TN, USASearch for more papers by this authorFurqan Hameed Khan, Furqan Hameed Khan School of ITEE, The University of Queensland, St Lucia, Brisbane, QLD, 4072 AustraliaSearch for more papers by this authorMarius Portmann, Marius Portmann School of ITEE, The University of Queensland, St Lucia, Brisbane, QLD, 4072 AustraliaSearch for more papers by this author First published: 09 November 2020 https://doi.org/10.1049/iet-com.2020.0335Citations: 5AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Abstract Software-defined networking (SDN) is an emerging technology of efficiently controlling and managing computer networks, such as in data centres, wide-area networks, as well as in ubiquitous communication. In this study, the authors explore the idea of embedding the SDN components, represented by SDN controller and virtual switch, in end-hosts to improve network performance. In particular, the authors consider load balancing across multiple network interfaces on end-hosts with different link capacity scenarios. The authors have explored and implemented different SDN-based load-balancing approaches based on OpenFlow software switches, and have demonstrated the feasibility and the potential of this approach. The proposed system has been evaluated with MultiPath transmission control protocol (MPTCP). The proposed results demonstrated the potential of applying the SDN concepts on multi-homed devices resulting in an increase in achieved throughput of 55% compared to the legacy single network approach and 10% compared to the MPTCP. 1 Introduction Software-defined networking (SDN) is a relatively new paradigm for controlling and managing computer networks. The new feature behind SDN is to separate and centralise the functionality of forwarding packets in traditional networking components from the actual packet forwarding mechanism. The logically centralised (software) controller or network operating system (NOS), provides an abstraction of the distributed nature of the forwarding elements (switches and routers) to higher-layer networking applications, such as routing, traffic engineering etc. Fig. 1 shows the traditional SDN architecture [1]. The bottom (infrastructure) layer consists of a set of connected forwarding elements, i.e. SDN switches, which represent the data plane and provide basic packet forwarding functionality. In this paper, we extend this traditional view by adding end-hosts to this layer. Fig. 1Open in figure viewerPowerPoint SDN architecture The middle layer is the control layer, which consists of a centralised SDN controller and implements the functionality of a NOS [2]. The NOS deals with and hides the distributed nature of the physical network, and provides an abstract view of network graph to higher layer services running over the application layer of the SDN architecture [3]. The SDN controller configures SDN switches by installing forwarding rules via the so-called southbound interface. The predominant standard for this is OpenFlow [4, 5] that will be discussed in more detail in Section 2. At the top of the SDN architecture is the application layer, where network applications and services, such as traffic engineering, routing, load balancing etc. are implemented. The research on SDN has so far mostly focused on the management of network infrastructure devices, i.e. forwarding elements, and has been highly successful in practical deployments, in particular in data centres and wide-area networks (WANs) [6, 7]. In contrast to the existing body of research, in this paper, we are exploring the idea of pushing SDN onto the end-host, which can be a normal computer, smartphone, a networked embedded device or a thing. For this, we consider to use the case of network load balancing. We assume an end-host with multiple network interfaces, e.g. a smartphone with 4G and WiFi, and consider the problem of efficiently balancing the user traffic across the available interfaces. When designing our mechanism, we attempted to meet the following objectives: Be efficient, and not introduce a significant amount of overhead on the host. Be transparent to both the applications as well as the rest of the network. Neither the applications nor the protocol stack of any other nodes in the network should have to be modified. Avoid packet reordering, and the associated detrimental impact on transmission control protocol (TCP) performance. Work with any OpenFlow compliant software switch and controller, from version 1.3 onwards. Moreover, although most earlier research efforts on SDN-based network evaluations [8] use Mininet. Nonetheless, the Mininet network emulator has issues such as, it mainly supports wired network topologies, it does not offer greater network scalability and uses a shard Linux kernel space for all virtual hosts [9]. The latter greatly impacts the design of the proposed system and has a separate control on the SDN-based end-host from other network elements. Therefore, it is necessary to either enhance Mininet capability or use other evaluation tools that provide greater flexibility in one or the other domain. For this reason, a compatible network emulation testbed, graphical network simulation (GNS3) [10], has been used in this work where the network elements are added as VMs with the support of separate kernel stack for each end-host VM. While the idea of controlling network traffic in multi-homed end-hosts using SDN has been primarily explored in [11], in this paper, we extended that contribution via employing different load-balancing algorithms with the aim of achieving the above goals. In [11], the evaluation was mainly conducted when the capacity of the links is static, while in this work the realistic network scenario with dynamic link capacity is considered. The algorithms are also evaluated with MultiPath TCP (MPTCP) [12]. While the MPTCP protocol requires control over both ends of the connection, in contrast, the approach in this paper focuses on controlling only the end-host connection. Our findings reveal that the SDN-based traffic control over end-hosts can noticeably achieve higher performance compared with the use of a single network interface. Further to that, our system demonstrated even better than MPTCP with the advantage of controlling the client-side only. The rest of the paper is organised as follows. Section 2 briefly introduces OpenFlow and MPTCP. Section 3 describes related works in applying SDN to end-host traffic control. Section 4 explains our proposed approach and Section 5 describes different load-balancing algorithms used to control and distribute the application layer traffic on the end-host. Section 6 describes the system implementation and the experimental setup. Sections 7 and 8 demonstrate the evaluation results of the implemented system with static link and dynamic link capacity scenarios, respectively. Finally, Section 9 summarises our findings and concludes the paper. 2 Background This section provides an overview of a well-known south-bound interface (e.g. OpenFlow). Then we introduce a well-known transport layer technology (MPTCP) that enables utilising multiple network interfaces on the end-host for a single connection. 2.1 Openflow OpenFlow [5] is currently the dominant southbound interface protocol for SDN, which allows controllers to configure the forwarding behaviour of switches. It provides the interface between the infrastructure layer and the control layer, as shown in Fig. 1. OpenFlow allows a controller to install rules as flow table entries in SDN switches via Flow-Mod messages. The installed entries follow a match-action paradigm and enable fine-grained control over how packets are being forwarded in the network. Each packet arriving at a switch is matched against the match fields of these rules, and the corresponding action/action list of matching rule is executed. The supported match fields include packet header fields, such as IP source and destination address, media access control (MAC) source and destination address, virtual local area network (VLAN) tags etc. An action may ask a switch to perform one or more of the following, • Forward the arriving packet to the controller or to next connected element by forwarding it through the corresponding port (action:output). • Modify/rewrite the specific packet header fields (action:set-field). For example, this allows the rewriting of IP and MAC addresses to implement address translation. • Drop the packet (action:drop). The OpenFlow protocol allows gathering switch statistics that may leverage for achieving various network functionalities, like load balancing. Certain types of OpenFlow messages, such as Port Stats and flow Stats messages, can probe information related to links, ports and flow entries on the enabled switch(es). The controller can request statistics of active ports by sending a PortStatsRequest message to the switch; then, the latter replies with a PortStatsReply message, with the probed information related to each port. Example of these are the cumulative number of sent and received packets and bytes, as well as the number of packets that have been dropped or had errors. The controller can also collect statistics about the active flow entries installed on the switch(es) through sending a FlowStatsRequest message, upon which the switch replies with a FlowStatsReply message. The message carries information related to each installed entry, for instance, table_id, priority, the number of bytes/packets that matched the rule, the active duration of the flow and the match/action fields. In this work, we will use the set-field and output action features in our load-balancing mechanisms discussed in Section 5 as well as port stats message in the result validation in Section 6. 2.2 MultiPath transmission control protocol MPTCP is an extension of TCP that exploits multiple paths to deliver versatile network services to the end-hosts. The use of MPTCP increases with the advent of new devices supporting operation with multiple networks (e.g. 3G/4G, WiFi). As a consequence, it is important to make efficient use of multiple paths at the same time. To address this issue, [13] shows that with careful monitoring and path updates it is possible to linearly increase network throughput multiple times for an MPTCP connection as new sub-flows are added. As shown in Fig. 2, a multi-path (MPTCP) connection is basically a thin layer that operates in between the application and TCP layers and provides features for the creation, management, and termination of TCP sub-flows. Similar to the normal TCP operation, a sub-flow starts when the host exchange SYN, SYN-ACK and ACK messages as shown in Fig. 2 [14, 15]. The first SYN (handshake) message includes a new option called MP_CAPABLE (in Fig. 2) to check if the other end supports MPTCP protocol; and if not, the connection falls to a normal TCP connection. In case the MPTCP is supported, a 64-bit authentication key, as well as, additional flags related to each end will be generated and exchanged via the added option. These fields are required in the later stages for the creation and authentication of TCP sub-flows. A typical flow can be added/removed from the MPTCP connection using ADD_ADDR/REMOVE_ADDR fields added as an extension for MPTCP. Ones all data is sent, the sender use DATA_FIN option to indicate that all data has been sent/acknowledged as shown in Fig. 2. The sender then closes the MPTCP connection over each sub-flow using the FIN flag (as in TCP) which is later acknowledged by the other end. To achieve backward compatibility, the normal reset/finish signals (RST/FIN) signal is exchanged for each sub-flow in MPTCP, as shown in the connection termination phase in Fig. 2. To terminate an ongoing session immediately, an MPTCP level closure (called MP_FASTCLOSE) is also included. This command tells the peer entity that the connection needs to be immediately closed and no data will be accepted anymore [14]. Upon reception, the other end either sends the MP_FASTCLOSE to close the whole connection or it can send the TCP RST on each sub-flows to close them one by one. Fig. 2Open in figure viewerPowerPoint MPTCP operations In a new transport layer solution such as the MPTCP it is challenging to devise flow control and congestion control approaches that achieve optimal network throughput. In other words, flows in an MPTCP connection should achieve their throughput without unfairly affecting the other (normal TCP) flows in the network. Moreover, the deployment of MPTCP needs control over the operation of both ends during the connection lifetime. Traditional Linux kernels (2.6.19 onwards) and some Windows operating system editions use TCP cubic as a default congestion control algorithm [16] which is optimised for high bandwidth and high latency networks. Compared with other congestion control algorithms, TCP cubic uses the time since most recent congestion event to update the congestion window. The size of the congestion window follows a concave shape before the congestion event after congestion detected; the window size follows a convex shape. 3 Related works SDN and OpenFlow have been used for load balancing in previous works, however, mostly at the server and in the network infrastructure. In previous works, the SDN-based load-balancing solutions are considered running over servers inside the network infrastructure. For example, the Plug-n-Serve solution presented in [17] provides an SDN-based solution for minimising the HTTP request–response time. The idea is to balance the web traffic (HTTP requests) across a number of web servers and network paths. As another example, the OpenFlow-based server load balancing is presented in [18]. The paper addresses the problem of scalability in data centre networks by using the wildcard flow rules. The load-balancing decisions are made based on source IP addresses, which is not applicable in our scenario of client-side load balancing. An initial effort of developing network solutions over end-host is the Eden system [19]. The work allows end-hosts to implement a wide range of application-aware networking functions, including path-based load balancing. However, this work does not address the issue of balancing traffic load across multiple host interfaces. Another key contrast to our work is that the Eden system is not transparent to applications or the network infrastructure, and hence cannot be easily deployed. In [15], the authors present a multipathing and load-balancing solution based on OpenFlow. The proposed method uses OpenFlow only for the network infrastructure and not for the end-host. Furthermore, end-hosts (client and server) need to use MPTCP as the transport protocol to make use of the load-balancing feature. Different previous works propose new congestion control algorithms for MPTCP [20]. For example, alias linked increase algorithm (LIA), alias opportunistic LIA, alias delay-based congestion control for MPTCP wVegas and alias balanced linked adaptation congestion control algorithm (BALIA). Likewise, different approaches for sub-flows management have been proposed to efficiently distribute MPTCP traffic between different sub-flows. To reduce the complexity of the multi-path problem in MPTCP, in this paper we suggest a client-side solution that requires the control only one end. Similar to TCP, MPTCP also allocates traffic per-packet basis. Contrary to this, in our work, the traffic allocation is done on a per-flow basis. In other words, our system runs over an end-hosts and enable it to distribute the traffic of each flow over the suitable network interface. The authors of [21] present an approach that allows the use of multiple network interfaces on end-hosts. Their system is implemented in Android and uses an OpenFlow switch for controlling the network traffic. Their paper discusses network handover, interface aggregation and dynamic interface selection. Most of the proposed mechanisms require both ends of the connection to support the special network protocol and stack, which is in contrast to our work. Furthermore, while discussing various aspects of using multiple host interfaces, [21] does not address the specific problem of load balancing. Some initial efforts for implementing SDN-based load-balancing solutions for end-devices are made in [22, 23]. In [22], the authors implement a proactive load-balancing approach for SDN-based machine-to-machine networks where short response time is desired. Real testbed evaluation of the proposed framework shows that it can minimise the device's response time to around 50% of the non-SDN approaches. Note that in contrast to our work, both the OpenFlow capable hardware SDN-switch and the controller (running traffic-aware load-balancing algorithm) used in their framework exist outside the end-device. Moreover, most earlier load-balancing solutions in the SDN-based network environment use Mininet [24]. For example, in [8, 23] the work uses mininet to implement traffic load balancing scheme using the virtual SDN (vSDN) controller. [23] develop an approach of SDN-based load-balancing for underwater acoustic sensor networks with multiple controllers. In the proposed proactive load-balancing algorithm [8], the primary vSDN controller creates a secondary vSDN controller as its new copy based on traffic load-balancing demand. The overall process of new controller inclusion is transparent to the end-user. In this way, the control plane can be extended based on traffic load leading to about 50% reduction in average load and 41% decrease in the average delay. Other proposals of traffic load balancing include [25], where the authors implemented a customised OpenFlow-based SDN controller to distribute traffic in the backhaul and access of cellular networks. In contrast to the above contributions, this paper aims to achieve traffic load balancing across multiple end-host network interfaces. This paper is an extension of our earlier work where SDN was applied for traffic control on multi-homed end devices [11]. This earlier work demonstrated the basic concept but was limited to the case of static link capacities. In contrast, this paper considers the case of dynamic link capacity, which is critical in wireless networks. A key contribution of this paper is an extensive experimental evaluation based on a realistic wireless network scenario, as well as a performance comparison with MPTCP. 4 Proposed system The basic architecture of our host-based network load-balancing mechanism using OpenFlow is shown in Fig. 3. In this scenario, the host has only two interfaces, but our approach is generalised for any number of interfaces. Fig. 3Open in figure viewerPowerPoint System architecture OpenFlow switch is the key component that facilitates the load balancing on the host with its ability to control the flow of network packets. The switch is configured to control the host's external network interfaces, in this case eth0 and eth1 in Fig. 3. In order to provide the required level of indirection to switch traffic between these interfaces in a way that is transparent to the application, we also configured a pair of (connected) virtual network interfaces (shown in Fig. 3 as veth0 and veth1). Interface veth0 is attached to the switch and veth1 is configured as an internal gateway via which all application traffic is sent. This is achieved via the configuration of a corresponding default route in the kernel's routing table. With this setup, the switch can implement traffic load balancing by choosing an external interface e.g. eth0 or eth1 through which the packets are sent, depending on the match-action rules installed on the switch by the controller [In our system, the controller is co-located on the host. However, this is not a requirement, and in future work, we will explore the idea of delegating control to a remote controller.]. From the system architecture of Fig. 3, as we have detached the application from directly communicating via an external-facing interface, we need to address a couple of issues, i.e. address translation and ARP handling. Address translation is required, since packets leaving the host need to have the correct IP source address as well as the MAC source and destination address, depending on which interface was chosen as the egress interface by the load balancer. This needs to be implemented for packets in both the forward and reverse directions. OpenFlow provides a packet header rewriting mechanism, which allows the implementation of address translation for both IP and MAC addresses. This is achieved in OpenFlow by adding a corresponding set-field action prior to the output action. The other issue is ARP handling. In a traditional system, when a host tries to send an IP packet to a particular destination, it would look up the address of the next-hop node and the corresponding interface in the routing table. Then, an ARP request is issued in order to establish the MAC address that belongs to the next-hop IP address. The ARP request is broadcasted on the local network, and the node with the specified IP address answers with an ARP reply message that contains its MAC address. Due to the level of indirection introduced in our setup, this does not work. We, therefore, implement a Proxy ARP mechanism, in which the switch intercepts any ARP requests from the host and sends them to the controller. The controller then instructs the switch to send an ARP reply message with the required MAC address. 5 Load-balancing approaches Since a key requirement of our load-balancing approach is the avoidance of packet reordering in a TCP session, we need to guarantee that all packets belonging to the same TCP session are sent via the same host network interface. To achieve this, we perform load balancing at the level of granularity of TCP connections [While the discussions in this paper is focused on TCP traffic, the same basic load-balancing approach can be applied to UDP traffic [26].]. We consider two basic approaches of SDN-based load balancing on the end-host, to which we refer as the controller-based and switch-based approaches. These methods are discussed in the following. 5.1 Controller-based load-balancing approach In this approach, load-balancing decisions for each individual TCP session are made by the SDN controller. The controller is responsible for allocating a TCP flow for a specific network interface. The switch sends the first packet of each TCP session, referred to as TCP SYN packet, which is initiated by an end-host application to the controller via Packet_In message. Among multiple interfaces and based upon the load-balancing algorithm, the controller will decide which interface should be chosen for forwarding that TCP flow. Then, the controller will install a flow entry on the switch via Flow-Mod message to send out not just the first packet, but also the rest in that TCP session via the selected interface. Algorithm 1 (see Fig. 4) shows the processing of packets received from the switch at the controller. The controller checks if the packet is a TCP SYN packet, and then assigns an interface i to the new flow, from the available N interfaces using a certain interface selecting algorithm Link_Select_Algo() discussed later in this section. Once the interface is chosen, the controller initiates an OpenFlow rule R, with 3 match fields (lines 6–8) and 4 actions (lines 9–12). The rule will match on TCP/IP packets and the specific source port of the received packet (line 8). In our scenario, the TCP source port will uniquely identify all TCP packets belonging to this session. The setField actions in lines 9–11 provide the required address translation, as discussed earlier. The output action in line 12 will instruct the switch to forward the packet via the chosen interface i. Finally, line 13 installs the rule R on the switch. Fig. 4Open in figure viewerPowerPoint Algorithm 1: Controller-based load balancing At this point, the switch sent all packets belonging to this TCP session via the chosen interface, without any further involvement of the controller. The load-balancing algorithms are categorised into stateless and stateful algorithms. While the former category does not take the link status parameters (e.g. bandwidth, the level of congestion, delay characteristics etc.) into consideration when opting the link, the latter considers link parameters in the link selection process. 5.1.1 Stateless load balancing: round robin (RR) algorithm In this category, we implement a simple approach that alternatively allocates the TCP flows among the available network interfaces without taking into account the link parameters. The process of opting the network interface (step 4 in Algorithm 1 (Fig. 4)) is done by allocating the new flow to the next available network interface which is simply done via the modulo operation as stated below. where FlowCounter represents the increasing flow counter and N is the number of available network interfaces connected to the end-host. 5.1.2 Stateful link selection Contrary to stateless link selection, in this approach, a link/interface is chosen based on its current state. The proposed system architecture is capable of controlling network traffic via utilising different network parameters, such as delay, packet loss and available bandwidth. In a previous paper [27], we have demonstrated how packet-loss ratio and delay can be used for selecting the optimal network interface for VoIP sessions. In contrast, this paper considers the available link bandwidth as the criterion for allocating flows to network interfaces. Two types of controller-based-stateful load-balancing algorithms will be discussed in this part, namely: maximum bandwidth (MBW) and the weighted round robin (WRR) link selection. (i) MBW link selection: In this algorithm, the controller allocates a TCP flow to the link having MBW among the available links. Hence, the step 4 for selecting the interface in Algorithm 1 (Fig. 4) is determined from the following equation: (1) where is the selected network interface, is the bandwidth of link j at time and is the number of available network interfaces. The above equation utilises argmax function that selects the interface i that has the MBW 'BW' among the available network interfaces N for allocating a new flow. For computing the link bandwidth, a link monitoring module runs in the background that collects and computes link status parameters such as the bandwidth per time basis [28]. The bandwidth computation is briefly explained in Section 8. As stated, our approach utilises one link (having the maximum residual bandwidth) among the available links. Note that this algorithm achieves uniform traffic distribution only over a small time duration. This is because it allocates new flows to the instantaneous maximum residual bandwidth link and continue forwarding the previously allocated flows to the link that had the MBW. In the next algorithm, we focus on achieving a better link utilisation over the whole duration through load balancing. (ii) WRR algorithm The previous algorithms either alternatively selects the network interface without considering its status (as the use of RR) or they choose the link with the highest bandwidth (when MBW is used). Both methods lack in efficient utilisation of available links for simultaneous traffic forwarding which can degrade the network performance. One of the approaches that try to improve the link utilisation and addresses the previously mentioned shortcomings is WRR. The approach proportionally allocates network flows based on the available bandwidth of the links as described below. Firstly we find the weights of the links based on their available bandwidth as stated below (2) where: is the weight of link j computed at time , is the bandwidth of link j at time and is the number of available links/ interfaces on the end-host. The weight of a certain link at time is the percentage of the bandwidth of that link over the total bandwidth of the available links at that time. Similar to the BW process computation, the process of computing the links' weight is also done as a background process. To ensure fair bandwidth utilisation of available links, traffic allocation should be done in an interleaved manner. Otherwise, the system either ends up using only one interface or it may inefficiently select links to forward traffic. Algorithm 2 (see Fig. 5) explains the Link_Select_Algo() function that selects the network interface using WRR algorithm. Brief