Fat Tree Network Topology

Published Date: 02 Nov 2017

ABSTRACT

Data centers of today are equipped with very high bandwidth capacity, high redundancy in both the core and distribution layer of the network by means of multipath. Data center networks host different applications that require high throughput, predictable latency, and minimal delay, these networks suffer from congestion due to the frequent variations and changes of their workload. The overall computational power of these data centers are to a large extent reduced due to bottlenecks in the network. In order to meet the requirements of today’s data centers and effectively utilize network resources, it is required that the network effectively distributes different flows to different paths, thus maximizing the utility of the redundant links and eliminating traffic bottlenecks. This poses a problem in current TCP implementation.

CHAPTER 1

INTRODUCTION

1.1 Introduction

Data Centers are the home of high speed computational power, efficient storage and necessary applications that are required to support enterprise businesses and solutions. Adequate planning of the Data Center Infrastructure design is vital and careful consideration must be given to its scalability, flexibility, resiliency, performance and quality of service. As the modern day data center evolves to a dynamic, scale-out and virtualized service stage, reevaluation of old trends, technologies, architectures and protocols needs to be carried out to determine if a more efficient way of designing them exist.

Current approaches in networking are most times based on establishing a single connection from a host device to the network. However, if most or all of the available connections are utilized in parallel, and in the case of a link failure, traffic is redirected to an operational path; the overall efficiency of the network will be significantly improved.

Load Balancing is vital in order to utilize the available multiple paths to a destination concurrently and to simplify the process of communication between the individual nodes and networks as opposed to the case of data transmission via a single path. If several paths exist from source node to destination with different characteristics, how can these paths be utilized with maximum effectiveness?

Our contribution to this study is to carefully examine the existing load balancing schemes either at packet level or flow level, investigate the performance difference between these schemes and propose a new scheme that will effectively combine the advantages of the existing implementations.

Load balancing can be carried out at different layers of the Open System Interconnect (OSI) model, the transport layers is the optimum and best place to implement and standardize this mechanism [Don07] since it has the most accurate information about the end to end paths. In this study, our focus is on the network with emphasis on the transport layer.

1.2 DATA CENTER ARCHITECTURE

Traditional Data Center topologies as shown in Figure 1 are tree based with poor performance, bottlenecks, single point of failures and no fault tolerance [Gre08].

Figure 1: Traditional Data Center Architecture

However, modern trends have seen a shift towards a redundant multipath topology and have been adapted by various data centers worldwide. Figure 2 below is a Fat-Tree Data Center topology adapted by Cisco Systems [Www01], [Www03].

Figure2: Fat Tree Network Topology

A fat-tree topology as shown in Figure 2 above has an aggregate bandwidth that increases in proportion to the number of host ports that are in the system and thus, a network can be said to be scalable if increasing the number of ports in the network amounts to a linear increase in the delivered bisection bandwidth [Moh08]. Scalability and reliability are therefore coherent since a robust and efficient network is a requisite for expanding a network size. The network is a hierarchy spanning from layers of servers fitted into a rack at the bottom to a layer of Core Switches at the top. A typical data center will consist of around 25 to 40 servers in a single rack, each connected to a Top of Rack (ToR) switch with a 1 Gbps link. The top of rack switches are connected to two aggregation switches basically to have a redundant network, these switches are further aggregated connecting to access switches/routers. The data center core routers move traffic between the access routers/switches and are responsible for managing all traffic in and out of the data center. All of the links utilize Ethernet as a Layer 1 (physical Layer) protocol, with a combination of copper and/or fiber cabling. All switches below each pair of access routers/switches form a single layer2 domain [Www01].

As can be seen from the fat-tree topology, it is necessary to utilize all available links for data transmission while maintaining connectivity by means of load distribution and traffic engineering. Naive and random allocation of resources might pose a huge problem and may give rise to poor performance.

Current data center implementations make use of TCP/IP over fast Ethernet and/or gigabit Ethernet for data communications thus limiting the maximum capacity of requests it can efficiently handle. Data Centers also arguably lack in requirements for managing limited physical resources, load-balancing, controlling congestion and overload, traffic prioritization, and quality of service.

Transport layer protocols such as TCP do not possess the ability to select paths based on the traffic load requirements [Xin12], [Moh08]. To overcome this limitation, series of research like in [Moh08], [Moh10], [Rai11], [Hop00], and [Xin12] have been and is still being carried out to develop a dynamic path selection mechanism that will take advantage of the multiple redundant paths connecting any host pair. These mechanisms can be broadly categorized into: centralized dynamic path selection mechanisms and distributed load balancing mechanisms [Xin12]. Although these mechanisms have the advantage of improving the data center network bandwidth, they also possess a number of disadvantages.

A centralized dynamic path selection technique gives room for a single point of failure and can introduces a bottleneck as a result of high network utilization. Control and signaling traffic from the centralized controller to the data center hosts and devices may induce congestion.

Distributed load balancing mechanisms perform well in large data centers, but may create traffic bottlenecks in small or medium sized data centers as their flow scheduling algorithms do not put into consideration the dynamic nature of the load on each path in the network [Xin12].

1.3 Traffic engineering in data center networks

Traffic Engineering mechanisms are fast becoming a requirement in modern data centers because not only are data centers required to operate with a very high performance, they are also to do so in a way to ensure the least downtime, degradation and maximum scalability. Although research may still be ongoing, there is no clear-cut mechanism to achieve this goal.

When congestion occurs the most important traffic should be made to get access to the links. Understanding how the network flows are distributed is vital for adequate planning and traffic engineering. The principal objective of a load balancing technique is to direct traffic in order to avoid congested links.

Chapter 2

Load Balancing in the Fat Tree Based Data Center Networks

Load Balancing is a very important feature of a multipath communication network in order to make optimal use of bandwidth [Mak12].

Data Center traffic patterns are often unpredictable and highly volatile. The aim is to develop a load balancing scheme that will effectively minimize the consumption of network resource, while providing load balancing and the least possible interference in a simple and feasible way. A few algorithms like Hedera [Moh10], DARD [Xin12], and ECMP [Hop00] have already been developed to this effect. The decision on a suitable load balancing algorithm will most times be determined by the application requirements. Packet level traffic distribution may not be suitable for applications requiring packets to arrive at the destination in the correct order while flow level traffic distribution will suit this requirement.

2.1 DATA-CENTER TRAFFIC ANALYSIS

Traffic in a data center network can be measured and generalized according to flows; flows are a sequence of packets from a source host to a destination host [Den12]. In relation to Internet Protocols, a flow can be defined to further include a specific source and destination port number and also transport protocol (E.g TCP or UDP).

Traffic is not symmetrical with very high client to server requests but small in general. Larger flows are experienced in server to client responses and are also application dependent [Den12], traffic from the Internet becomes severely aggregated thus; the average traffic flow remains little because the aggregated flows exhibit a very high degree of variability. In general, most flows in data centers are small in size and about less than 10 kilobytes, bigger flows are of a very small fraction.

A survey of a typical data center network [Www07] was carried out taking trace files from one of the network hotspots by collecting netflow statistics and a packet sniffing application and the following observations were made:

In an approximate time of eight minutes, TCP bytes out numbers all other transport protocols as show in Figure 3a and Figure 3c

capturesummary.PNG

Figure 3a: Data Center traffic summary from the analyzed trace files

The number of occurrences of the different TCP errors in the period under observation due to out-of-order packets, lost segments, duplicate acknowledgements and resets as shown in Figure 3b is considerably high causing a significant amount of the packets to be retransmitted. This can be improved upon.

tcp errors.PNG

Figure 3b: Number of TCP errors recorded over time

A huge percentage of data center traffic such as web browsing, telnet, File Transfer Protocol (FTP) and secure shell are TCP based as shown in Figure 3c. If an efficient way can be developed to effectively deliver these packets, an overall improvement in the system performance will be achieved.

protocoldist.PNG

Figure 3c: Data Center Protocol Distribution in Bytes

2.1.1 Data Center Core Layer

The data center core layer provides a means for high speed packet switching between the lower layers. This layer functions as interconnecting point between the aggregation layer and other network modules [Www01]. All links connecting the data center core are terminated at the network layer (layer 3 interfaces) and use 10 Gigabit Ethernet interfaces to support a high level of performance.

A data center core layer on its own is not necessarily required, but is largely useful when several aggregation modules are to be used for scalability and expansion. In the case when a relatively small number of modules are used, it is appropriate but not necessary to use the data center core layer for interconnection the fabric from the aggregation layer of the data center [Www01].

2.1.2 Traffic Flow in the Data Center Core

The core layer connects to the aggregation layer using Layer 3 terminated 10 Gigabit Ethernet links. Layer 3 links are necessary in order to achieve a scalable bandwidth and to avoid paths getting blocked or the risk of broadcast storms as a result of expanding the layer two domains.

The traffic flow in the core layer consists generally of sessions traveling between the core and the aggregation layer. Traffic from the aggregation layer is aggregated to optimal paths in the network by means of the core layer. Server-to-server traffic however remains within the aggregation layer, although replication and redundant traffic can travel between aggregation layer modules by passing through the core layer [Www01].

2.1.3 Data Center Aggregation Layer

The aggregation layer comprises of a large number of access layer uplinks connected to it, and is responsible for aggregating the numerous sessions leaving and entering the data center. The aggregation switches should be able to support many 10 Gigabit Ethernet and 1 Gigabit Ethernet interconnections and at the same time providing a high-speed switching fabric with a high forward transmission rate. The aggregation layer also provides value-added services, such as load balancing to the servers across the access layer devices.

The aggregation layer switches carry the workload of spanning tree processing and default gateway redundancy protocol processing.

2.1.4 Traffic Flow in a Data Center Aggregation Layer

The aggregation layer connects to the core layer using Layer 3 terminated 10 Gigabit Ethernet links. Layer 3 links are used to enhance bandwidth scalability, optimal convergence, and to prevent paths from being blocked or the risk of broadcast storms as a result of extending the layer 2 domain.

The traffic in the aggregation layer is categorized into flows and can be a core to access layer flow or a flow within the access layer. The path selection techniques vary for different flows and are depend on the design parameters.

2.1.5 Data Center Access Layer

The access layer provides the physical level connection to the server and other network resources, and operates in Layer 2 or Layer 3 modes. These modes play a critical role in meeting particular server requirements. The access layer is a point of connection for network hosts like computers, printers and other end user devices. Spanning tree protocols are extended from the aggregation layer into the access layer, depending on which access layer model is used. Cisco [Www01] recommends implementing access layer switches in pairs of two by means of stacking in order to support server redundancy or to support a wide range of connections.

2.2 CONGESTION ANALYSIS AND NETWORK OPTIMIZATION

A global congestion control mechanism prevents the network from operating in saturated regions. Most networks utilize end-to-end flow control protocols, such as TCP, which uses a windowing mechanism between pairs of source and destination to match the source’s injection rate with the destination’s acceptance rate. TCP is designed for reliable packet delivery and not necessarily timely packet delivery; as a result, it requires additional tuning and optimization in order to balance its performance and thus, avoid unnecessary packet duplication from eagerly retransmitting packets under heavy traffic [Den12].

The main problem of network optimization is to avoid situations where the network is underutilized in some links and at the same time congested in some other links. Data Center Networks can be optimized using various objectives; one of such objective is by minimizing the maximum utilization in a normal scenario or a predefined failure situation.

CHAPTER 3

EXISTING LOAD BALANCING IMPLEMENTATIONS

3.1 Valiant Load Balancing (VLB)

Valiant introduced (VLB) as a randomized scheme for communication among parallel processors interconnected in a hypercube topology. Among its recent applications, VLB has been used inside the switching fabric of a packet switch. VLB has also been proposed, with modifications and generalizations, for oblivious routing of variable traffic on the Internet under the hose traffic model [Moh08], [Gre08].

VLB, in theory, ensures a non-interfering packet switched network, the counterpart of a non-blocking circuit switched network, as long as (1) traffic spreading ratios are uniform, and (2) the offered traffic patterns do not violate edge constraints. To meet the latter condition, VLB relies on TCP’s end-to-end congestion control mechanism. VLB guarantees equal spread load-balancing in a mesh network by bouncing individual packets from a source switch in the mesh off of randomly chosen intermediate core switches, which finally forward those packets to their destination switch [San10]. VLB can accomplish near optimum performance when the traffic is spread homogeneously at packet level and when the traffic patterns obey the edge constraints [Gre08]. A key limitation is that it can only be applied at flow level and as such, all packets in one flow will transverse the same path. This is not suitable for non-uniform network traffic, when multiple flows are routed via a single link, congestion may occur.

3.2 Equal Cost Multipath (ECMP)

A good topology is one that has sufficient path diversity in which multiple possible output ports may exist, having each one leading to a unique network path. Path diversity may yield ECMP (equal-cost multipath) routing; in this case the routing algorithm attempts to load-balance the traffic flowing across the links by spreading traffic uniformly [Hop00]. To accomplish this uniform distribution, the routing function in the switch will hash several fields of the packet header to produce a deterministic output port. In the event of a link failure, the routing algorithm exploits the advantages of path diversity in the network to discover another path. This static mapping of flows to paths does not account for either the current network utilization or the flow size, with resulting collisions overwhelming the switch buffers and degrading the overall switch utilization. Another key limitation of ECMP is that two or more large, long-lived flows can collide on their hash and end up on the same output port, creating an avoidable bottleneck. ECMP applies load balancing for TCP and UDP packets on a per flow basis. Non TCP or UDP packets are distributed packet-by-packet. ECMP is an RFC 2991 standard [Tha00].

ecmp.PNG

Figure 4: ECMP Load Balancing

3.3 HEDERA

Hedera [Moh10] collects flow information from constituent switches, computes non-conflicting paths for flows, and instructs switches to re-route traffic accordingly. It uses a central controller to compute an optimal flow-to-path assignment based on dynamic traffic load [Moh10]. A central scheduler, possibly replicated for fail-over and scalability, manipulates the forwarding tables of the edge and aggregation switches dynamically, based on regular updates of current network-wide communication demands. The scheduler aims to assign flows to non conflicting paths; more specifically, it tries to not place multiple flows on a link that cannot accommodate their combined natural bandwidth demands.

3.4 Spanning-Tree/VLAN

Conventional Ethernet utilizes Spanning Tree Protocol (STP) for frame forwarding, which always reduces a meshed network topology to a tree by blocking some links and ports from forwarding status and thus eliminates forwarding loops from the network. However, STP also eliminates the multipathing capability and shows poor bandwidth utilization for such a meshed Ethernet. The poor bandwidth utilization likely leads to congestion in the core/aggregation level as those switches need to carry aggregated traffic from all end stations in the network, especially with the deployment of 10GE, where the backbone links are 10Gbits/s and end stations also connect to the tree structure with 10GE ports. Hence, traditional Ethernet deployed with STP cannot scale well to support data center.

3.5 Multipath TCP (MPTCP)

Most applications use single path TCP, and inherit TCP’s congestion control mechanism which does a fair job of matching offered load to available capacity on whichever path was selected. Recent research has shown there are benefits from tuning TCP for data center use, such as by reducing the minimum retransmit timeout, but the problem TCP solves remains unchanged [Rai11]. MPTCP can establish multiple sub flows across different paths between the same pair of endpoints for a single TCP connection. The key point is that by linking the congestion control dynamics on these multiple sub flows. MPTCP spreads application data over multiple sub flows; it then runs the NewReno congestion control algorithms individually and separately for each separate path, so that each path would have its own window that will reflect the paths available bandwidth [Flo04]. This implies that MPTCP can send fewer packets over the paths that have a small window or/and a large round trip time while sending the bulk of the packets over the paths with a large congestion window. By doing this, MPTCP can effectively handle congestion in the network by explicitly moving traffic away from the more congested paths and place it on the less congested paths.

Application

MPTCP

Subflow (TCP) | Subflow (TCP)

IP | IP

Table 1: MPTCP Protocol Stack

MPTCP uses a single window for congestion at the receiver end. It utilizes two set of sequence numbers at connection level and at sub-flow level and ensures two level of packet re-ordering. The receiving device must buffer all sub-flows for the period of the largest Round-Trip Time [Han10], [Rai10].

Data is retransmitted through a different sub-flow in the event of a sub-flow failure. MPTCP ensures that congestion is controlled within every sub-flow.

Although MPTCP arguably unites the path selection process and path control by transferring traffic to underutilized links, it is a new transport mechanism and thus would require replacing the current TCP stack [Rai11], [Gre08], [Rai10].

3.6 Data Center TCP

Data Center TCP (DCTCP) is a variant of TCP which leverages on the Explicit Congestion Mechanism and a feedback mechanism at the host device [Ali10a]. Its goal is to achieve low latency, maximum throughput and high burst tolerance with shallow buffered switches. This is achieved by reacting to congestion relative to the degree of congestion. Once the switch buffer exceeds a fixed threshold, the switch sets the Congestion Experienced codepoint of the packets. The window is subsequently reduced by the DCTCP source by a factor depending on the fraction of marked packets [Den12], [Ali10a], [Ali10b]. A large fraction of marked packet will result in a bigger decrease factor. According to [Ali10a], DCTCP reduces queue Buildup, buffer pressure and Incast problems.

dtcp.PNG

Figure 5: DCTCP’s Performance in Many-To-One Scenario [Ali10a].

3.7 Queue-length directed adaptive routing

The Queue-length adaptive routing scheme utilized the routing schemes in high performance networks to data center networks [San10]. This works by choosing the output port that has the smallest queue length and can reach the required destination. The initial packet of the flow makes up the path to the destination and is based on the length of the queues of the output ports. When the desired path has been chosen, every other packet will be sent across the same path. This is done in order to avoid packets being out of order at the destination and is also implemented at flow level [San10]. This technique ensures that at the initiation of a flow, the least congested link will be chosen to make up the path.

3.8 Probing based adaptive routing

This technique makes the assumption that the source node can choose the path which a packet will transit and send a packet with a probe along that path [San10], [Gre08], [Cor10]. When an elephant [Mor04] flow needs to be sent by the source node, a network probe is sent by sending probe packets along the different redundant and accessible paths to the destination. The number of paths that will be probed from source to destination is a parameter to be determined by the scheme. When a node receives the first probe packet, it replies with an acknowledgement packet and drops every other probe packet for the flow. This acknowledgement packet contains the information about the path and thus making it possible for the source node to utilize this path for the transmission.

When large flows need to be sent, probing the network ensures that these large flows are never routed over bottlenecks or congested links thereby achieving a form of load balancing and effectively decreasing the chances of having network congestion.

3.9 Network load balancing

Network load balancing is an implementation by Microsoft Incorporation. It utilizes port rules to create a custom load balancing technique for a range of server ports [Sam09]. Port rules can select either a single-host or multiple-host load balancing policies. In multiple-host load balancing implementation, incoming client requests are simultaneously distributed among all hosts in the cluster by using layer-two broadcast or multicast, and a load percentage can be specified for each host. Load percentages allow hosts with higher capacity to receive a larger percentage of the total client load. In Single-host load balancing, all client requests are redirected to the host with the highest handling priority [Sam09]. The handling priority overrides the host priority for the port range and allows different hosts to handle all client traffic individually for specific server applications. Port rules can also be used to block unwanted network access to certain host or network device ports.

Network Load Balancing ensures scalability in the performance of server-based programs by sharing request form clients amongst multiple web servers contained in the cluster [Www02],[Ali10c]. IP packets in the inbound direction is received by every host like in the case of a broadcast, but accepted by the intended recipient. The hosts in the cluster responds to the different client requests concurrently, this makes processing faster and efficiently reduces the response time to clients.

3.9.1 Network load balancing algorithm

Network Load Balancing utilizes a fully distributed filtering algorithm to assign clients workload to hosts in a cluster [Sam09]. This algorithm ensures that hosts in a cluster are able to make a load-balancing decision very quickly and independent of each other for every incoming packet. It offers a (N-1)-way failover in a cluster with N-host and also high availability. This algorithm tends to be less effective when the population of client is small or when the load on the server varies considerably. The overall quality of this load balancing technique is determined by the number of clients making requests [Www02].

http://technet.microsoft.com/en-us/library/Bb742455.nlbovw06_big(l=en-us).gif

Figure 6: Throughput of Network Load Balancing compared to an ideal case as hosts are added [Www02].

3.10 Observations and analysis

From in-depth analysis of the existing load balancing implementations, MPTCP proved to be the most viable and thus will be used as a baseline in this implementation. MPTCP redefines TCP mechanisms so that they are suitable for multipath scenarios. By means of a congestion control mechanism, a host can regulate its total throughput accordingly in line with the available network resources. This is performed at the sub flow level with each sub flow utilizing its own congestion window.

With the existing implementation of TCP, packets tend to arrive out of order when there is a variation in the end-to-end delay, i.e. networks with large jitter [Chi11]. The out of sequence packets makes the receiver respond with duplicate acknowledgements. This may cause the sender to assume that a packet was lost wrongly.

In multipath scenarios, due to the different characteristics of the multiple paths and the network congestion state, packets may also arrive out of order. This poses a problem for MPTCP when packets are being reassembled at the connection level. To avoid packet reordering issues, two standardized [Leu07] algorithms used by TCP will be considered, the Eifel and the DSACK algorithm.

3.10.1 Eifel Algorithm

Figure 7: Eifel Algorithm

Figure 7 as shown above describes how Eifel algorithm [Leu07] [Lud03] works. A TCP timestamp option is inserted by a sending host in each of the transmitted segment. The receiving host then inserts the value of the timestamp of the received segment in the acknowledgment. If there is a loss, the sending host saves the value of the most recent congestion window and that of the slow start threshold. The sending host then retransmits the lost segment and stores the value of the timestamp [Lud03]. When an acknowledgement is received by the sending host for a segment that has been retransmitted, it compares the value of the saved timestamp with that inserted in the acknowledgement. If the first value is larger then retransmission can be considered illegitimate and the values of the congestion window and the slow start threshold are restored.

3.10.2 DSACK Algorithm

As illustrated in Figure 8, the DSACK Algorithm [Flo00] is based on Selective Acknowledgement option. When a segment that creates a hole in the sequence numbers is received, the receiver returns a duplicated acknowledgement including a Selective Acknowledgement (SACK) option. The sender only retransmits the lost segment only after three duplicated acknowledgements; it saves the value of the congestion window and goes into a Congestion Avoidance stage. Subsequently, the sender discovers the double acknowledgement of a retransmitted segment; it then infers an illegitimate retransmission.

Figure 8: DSACK Algorithm

3.11 mptcp algorithm vs. regular tcp algorithm

Regular TCP makes use of a generic window based algorithm for congestion control; this consists of a multiplicative decrease behavior in the event of a loss and an additive behavior in the absence of packet loss [Dam11]. On the reception of an acknowledgement, the congestion window w is increased by 1/w; this implies an equivalent increase in the number of packet by one per round trip time. In the event of a packet loss, the congestion window is decreased by w/2.

MPTCP maintains a separate congestion window for each of the sub-flows, a sending host stripes these packets amongst sub-flows as openings in the sub-flow window appear. If there is a loss in a sub-flow, the congestion window is decreased similar to the case of regular TCP but on a sub-flow basis. The round trip time is measured by the sub-flows.

Let denote the congestion window of a sub-flow traversing a path "r". The total congestion window is the sum over all paths of all congestion windows of sub-flows, i.e.

= + per acknowledgement on path r

= max ( , 1) per loss on path r

Chapter 4

SIMULATION AND INITIAL RESULTS

Our goal is to examine the existing load balancing mechanisms by identifying their flaws and limitations, propose a load balancing mechanism by combining the several advantages of the existing techniques, analyze a typical data center flow characteristics with the aid of network simulation tools to determine the most efficient way of load distribution across less utilized links and implementing traffic engineering with the required quality of service and to increasing the effective throughput of the data center network.

Multipath TCP was simulated using the network simulator NS-3 [Www04] to determine it’s performance and also to compare the various congestion control mechanisms. The source code of this implementation was modified from the hosted site at Google Code [Www05].

Figure 9: Simulated System as implemented in NS-3

The initial simulated system as shown in Figure 9above consists of a File Transfer Protocol Application to transfer a file running on a client/server architecture where the client hosts is equipped with two network interface cards and is connected by dual point-to-point links to the server.

Various scenarios of packet reordering and congestion control algorithms will be experimented as well as various network parameters like delay and bandwidth and also transmission parameters like packet size and buffer size to derive an optimum load balancing technique.

The Transport Layer in this multipath scenario is subdivided into two layers, the MPTCP sub-layer and the lower sub-layer. The MPTCP sub-layer initiates the sub-flows, establishes and manages the connections while the lower layer manages each allocated sub-flow.

4.1 SIMULATION STRUCTURE

MpTcpSocketImpl: This is a sub-class of the main class "Tcp-SocketImpl". It functions as to provide an application programming interface for the application layer to effectively manage the MPTCP connections, this sub-class also implements the algorithm for packet reordering as configured for the simulation and in this case the Eifel Algorithm

MpTcpL4Protocol: This is an interface that lies between the network layer and the multipath transport layer. It is a sub-class of the NS3 main class TcpL4Protocol.

MpTcpHeader: This is a subclass of the NS3 class "TcpHeader"

MpTcpSubflow: This is a sub-flow that originates from a MPTCP session.

The total transmitted byte from server to client was 10000000bytes with a configured buffer size of 1400bytes and a receiver buffer size of 2000bytes. The simulation duration was 200 seconds

4.2 SIMULATION RESULTS

From the simulation carried out, load balancing across the dual links was evenly distributed; the capture statistics as observed from the host nodes are show in Figure 10 below

0-1 capture.PNG

Figure 10: Wireshark capture statistics for interface 1 (IP Address 10.1.1.1)wireshark 0-2.PNG

Figure 11: Wireshark capture statistics for Client interface 2 (IP Address 10.1.2.1)

The total received packet was 10.7megabytes, this is 0.7megabytes in excess of the transmitted file of 10megabytes thus accounting for the total size of retransmitted packets. Although, the total number of retransmitted packet on each link cannot be deduced directly from Figure 10 and Figure 11, the total retransmitted packets are averaged over both links. The throughput graphs as shown in Figure 12 and Figure 13 indicate the effective throughput over the simulation period as captured from each clients interface, although the simulation was carried out for 200 seconds, the file was successfully transferred in a duration of approximately 20 seconds. Load balancing was achieved as expected as approximately half the size of the transmitted file was received via each connected path.

tcp through put zoomed.PNG

Figure 12: Throughput Graph for Client interface 1

tcp through put zoomed 2.PNG

Figure 13: Throughput graph from Client interface 2

Chapter 5

CONCLUSION AND FUTURE WORK

5.1 Conclusion

Results of experimentation has shown that although the MPTCP achieves load balancing and effective path diversity, Wireshark [Www06] examinations have show severely malformed packets as a result of out-of-order packet arrival causing a high rate of packet retransmission. The Eifel algorithm does not effectively solve the issue of out-of-sequence packets at the receiving host in the MPTCP implementation.

5.2 Future work

Our goal is to experiment with a variety of congestion control algorithms as well as packet reordering mechanisms by carrying out extensive simulations in order to access their impact and also develop the most optimal solution to load balancing while exploiting the advantages of the path diversity in the MPTCP implementation. The DSACK algorithm will also be incorporated in the MPTCP code and its performance will be compared to the case of the Eifel algorithm.

Data Center TCP as proposed by [Ali10b], [Ali10c] which leverages on the explicit congestion notification will also be considered in subsequent experimentation and in a possible Multipath Data Center TCP (MP-DCTCP) implementation. Upon successfully derivation of an appropriate and efficient packet reordering and load balancing algorithms, the simulation environment will scale up to consist of more network nodes in order to experience a near realistic data center environment.