Aggregating the Bandwidth of Multiple Network Interfaces to Increase the Performance of Networked Applications

Devices capable of connecting to two or more different networks simultaneously, known as host multihoming, are becoming increasingly common. For example, most laptops are equipped with a least a Local Area Network (LAN) and a Wireless LAN (WLAN) interface, and smartphones can connect to both WLANs and 3G-networks (High-Speed Downlink Packet Access, HSDPA). Being connected to multiple networks simultaneously allows for desirable features like bandwidth aggregation and redundancy. Enabling and making efficient use of multiple network interfaces or links (network interface and link will be used interchangeably throughout this thesis) requires solving several challenges related to deployment, link heterogeneity and dynamic behavior. Even though multihoming has existed for a long time, for example routers must support connecting to different networks, most existing operating systems, network protocols and applications do not take host multihoming into consideration. The default behavior is still to use a single interface for all traffic. Using a single interface is, for example, often insufficient to meet the requirements of popular, bandwidth intensive services like video streaming. In this thesis, we have focused on bandwidth aggregation on host multihomed devices. Even though bandwidth aggregation has been a research field for several years, the related works have failed to consider the challenges present in real world networks properly, or does not apply to scenarios where a device is connected to different heterogeneous networks. In order to solve the deployment challenges and enable the use of multiple links in away that works in a real-world network environment, we have created a platform-independent framework, called MULTI. MULTI was used as the foundation for designing transparent (to the applications) and application-specific bandwidth aggregation techniques. MULTI works in the presence of Network Address Translation (NAT), automatically detects and configures the device based on changes in link state, and notifies the application(s) of any changes. The application-specific bandwidth aggregation technique presented in this thesis was optimised for and evaluated with quailty-adaptive video streaming. The technique was evaluated with different types of streaming in both a controlled network environment and real-world networks. Adding a second link gave a significant increase in both video and playback quality. However, the technique is not limited to video streaming and can be used to improve the performance of several, common application types. In many cases, it is not possible to extend applications directly with multilink support. Working on the network-layer allows for the creation of bandwidth aggregation techniques that are transparent to applications. Transparent, network-layer bandwidth aggregation techniques must support the behavior of the different transport protocol in order to achieve efficient bandwidth aggregation. The transparent bandwidth aggregation techniques introduced in this thesis are targeted at Universal Datagram Protocol (UDP) and Transmission Control Protocol (TCP), the two most common transport protocols in the Internet today

Deliverable D2.1 - First Version of Low-Level Core Transport System

This document presents the first version of the low-level Core Transport System in NEAT, to be used for development of a reference implementation of the NEAT System. The design of this core transport system takes into consideration the Transport Services and the API defined in Task 1.3 and in close coordination with the overall architecture (Task 1.2). To realise the basic Transport Services provided by the API, a set of low-level transport functionalities has to be provided by the NEAT core transport system. These functionalities take the formof several building blocks, or NEAT Components, each representing an associated implementation activity. Some of the components are needed to ensure the basic operation of the NEAT System—e.g., a NEAT Flow Endpoint, a callback-based NEAT API Framework, the NEAT Logic and the functionality to Connect to a name. Some other components are needed to ensure connectivity usingMiddlebox Traversal techniques (e.g., TURN), discovery of path support for different transport protocols using Happy Eyeballs mechanisms, offering end-to end Security (e.g., (D)TLS over transport), gather statistics for the users or system administrators, and the ability to apply different policies in order to influence the decision-making process of the transport system. This document describes each of these building blocks and related design choices.A New, Evolutive API and Transport-Layer Architecture for the Internet (NEAT

Deliverable D2.2 - Core Transport System, with both Low-level and High-level Components

This document presents the core transport system in NEAT, as used for development of the reference implementation of the NEAT System. The document describes the components necessary to realise the basic Transport Services provided by the NEAT User API, with the description of a set of NEAT building blocks and their related design choices. The design of this core transport system takes into consideration the Transport Services and the API (defined in Task 1.3) and in close coordination with the overall architecture (Task 1.2). To realise the Transport Services provided by the API, a set of transport functionalities has to be provided by the NEAT Core Transport System. These functionalities take the form of several building blocks, or NEAT Components, each representing an associated implementation activity. Some of the components are needed to ensure the basic operation of the NEAT System—e.g., a NEAT Flow Endpoint, a callback-based NEAT API Framework, the NEAT Logic and the functionality to Connect to a name. Additional components are needed for: (a) ensuring connectivity, by means of mechanisms for discovery of path support for different protocols; (b) supporting end-to-end security; (c) the ability to apply different policies to influence the decision-making process of the transport system; (d) providing other important functionalities (e.g., a user-space SCTP stack, or gathering statistics for users or system administrators). This document updates Deliverable D2.1; in particular, the descriptions of NEAT components presented here correspond to the implementation status at the time of writing, and as such they replace those in D2.1.A New, Evolutive API and Transport-Layer Architecture for the Internet (NEAT

Deliverable D1.1 - NEAT Architecture

Ossification of the Internet transport-layer architecture is a significant barrier to innovation of the Internet. Such innovation is desirable for many reasons. Current applications often need to implement their own mechanisms to receive the transport service they need, but many do not have the breadth of adapting to all possible network characteristics. An updated transport architecture can do much to make the Internet more flexible and extensible. New ground-breaking services often require different or updated transport protocols, could benefit from better signalling between application and network, or desire a more flexible choice of which network path is used for which traffic. This document therefore proposes a new transport architecture. Such architecture lowers the barrier to service innovation by proposing a “transport system”, the NEAT System, that can leverage the rich set of available transport protocols. It paves the way for an architectural change of the Internet where new transport-layer services can seamlessly be integrated and quickly made available, minimising deployment difficulties, and allowing Internet innovators to take advantage of them wherever possible. The document provides a survey of the state-of-the-art to identify the architectural obstacles to, and opportunities for, evolution of the transport layer. It also details a set of general requirements for a new transport architecture. This new architecture is motivated by a set of use-cases, followed by a description of the NEAT architecture for a transport system, designed to permit applications to select appropriate transports based on their needs and the available transport services.A New, Evolutive API and Transport-Layer Architecture for the Internet (NEAT

Deliverable D2.3 - Final Version of Core Transport System

This document presents the core transport system in NEAT, as used for development of the reference implementation of the NEAT System. The document describes the components necessary to realise the basic Transport Services provided by the NEAT User API, with the description of a set of NEAT building blocks and their related design choices. The design of this core transport system, which is the final product ofWork Package 2, is driven by the Transport Services and API design from Task 1.4, and in close coordination with the overall NEAT architecture defined in Task 1.2. To realise the Transport Services provided by the API, a set of transport functions has to be provided by the NEAT Core Transport System. These functions take the form of several building blocks, or NEAT Components, each representing an associated implementation activity. Some components are needed to ensure the basic operation of the NEAT System—e.g., a NEAT Flow Endpoint, a callback-based NEAT API Framework, the NEAT Logic and the functionality to Connect to a name. Additional components are needed for: (a) ensuring connectivity, by means of mechanisms for discovery of path support for different protocols; (b) supporting end-to-end security; (c) the ability to apply different policies to influence the decision-making process of the transport system; (d) providing other important functionalities (e.g., a user-space SCTP stack, or gathering statistics for users or system administrators). This document updates Deliverable D2.2; in particular, the descriptions of NEAT components presented here correspond to their implementation status by the end of WP2, and as such they supersede those in D2.2.A New, Evolutive API and Transport-Layer Architecture for the Internet (NEAT