Community Research and Development Information Service - CORDIS

H2020

NEAT Report Summary

Project ID: 644334
Funded under: H2020-EU.2.1.1.3.

Periodic Reporting for period 1 - NEAT (A New, Evolutive API and Transport-Layer Architecture for the Internet)

Reporting period: 2015-03-01 to 2016-02-29

Summary of the context and overall objectives of the project

The Internet’s transport-layer architecture is, in some aspects, still dependent on developments dating from the 1980’s. Modern online applications need a more flexible transport architecture to rest upon, given the substantial changes that the usage of the Internet has undergone in the past decades. The new reality includes mobile users and no longer shows a clear separation between data communication and telecommunication services.

Smartphones and tablets can run an extensive variety of Internet applications, connected via networks such as WiFi and LTE; terminals such as laptops and desktop PCs add wired connections to the above mix of wireless network technologies. Besides, each application has its own requirements for how it wishes its data to be carried over the Internet. The communication needs of a sensor application differ from those of web browsing or remote conferencing applications. This diversity of needs and technologies currently requires application developers to consider the different networks their application may run on, and how to tune transport and network parameters for those networks – not an easy task.

The problem above is compounded by the fact that the current transport architecture of the Internet – as embodied by common Application Programming Interfaces (APIs) – exposes communication protocols to applications instead of services, and ties applications to a priori choices.

Moreover, ossification of the network infrastructure – as embodied by the ubiquitous middleboxes deployed on many networks – makes it very difficult for applications to pick and use modern transports that could provide a better service and improved performance.

NEAT will provide a new approach enabling developers to specify an application’s requirements in terms of rate, delay, reliability, cost, etc. This will allow NEAT to choose, or help choose, the best communication service. By separating services offered to applications from the underlying protocols and OS features, NEAT will enable automatic and transparent choice of the best transport options available. As network technologies and protocols continue to evolve, NEAT-enabled applications will immediately be able to take advantage of new functions to reduce web page download times, make teleconferences more responsive or reduce the cost of downloading a software update, getting whatever the application needs.

The NEAT Transport System is being designed to take care of:

● Offering an enhanced API between applications and the transport layer, so that it exposes transport services to applications.
● Implementing transport services in a best-effort manner, based on the protocols and functions that are available end-to-end along a network path.
● Providing transparent support for: (a) dealing with middleboxes; (b) discovering and leveraging end-to-end features; (c) interacting with the network for a better application experience.
● Enabling user-space protocol stacks.

Such features will allow the NEAT System to: (a) decouple applications from a priori choices of underlying protocols and technologies; (b) support incremental evolution and deployment of new transports; (c) relieve applications from the burden of implementing common mechanisms, and avoid “reinventing the wheel”.

Work performed from the beginning of the project to the end of the period covered by the report and main results achieved so far

In the first phase of the NEAT project, a strong focus has been put on the design of an extensible Internet transport-layer architecture. The architecture decouples communication services offered to applications from the underlying protocols, operating systems and platforms. This design work covers both the architecture of the NEAT Transport System and the API this system must provide to applications running on top of it. The design takes into account both: (a) a set of generic requirements a transport system must comply with, to be flexible and able to evolve; (b) specific applications related to the industry partners’ use cases. These applications cover a wide range of scenarios where the NEAT approach may provide benefits, from web browsing on mobile terminals to distributed storage solutions.

Work is ongoing towards providing a reference, open-source implementation of the core NEAT Transport System. This activity started by designing a set of core components. Core components include generic functionalities that are needed regardless of the use cases, like for instance an API code framework, mechanisms for discovering end-to-end support of some functions, or a policy manager. Implementation of these core components was started, currently focusing on the Linux, FreeBSD, MacOS X and NetBSD operating systems. The outcome of this activity is a user-space software library, currently under active development by the consortium, that implements the NEAT architecture and API. Even though this code is a work-in-progress and in early stages of development, NEAT believes in open code, hence why we have made it public already.

The third main activity since the project started has been in the standardisation area. To facilitate the broad adoption of NEAT outcomes, the project consortium is promoting its results at the Internet Engineering Task Force (IETF), in relevant working groups such as the Transport Services Working Group (TAPS) and the Transport Area Working Group (TSVWG). To date, project participants have co-authored eight Internet Drafts, of which four have already been adopted as Working Group Items – a first important step towards publication as IETF Requests for Comments (RFCs).

Progress beyond the state of the art and expected potential impact (including the socio-economic impact and the wider societal implications of the project so far)

There exist a range of point or partway solutions that try to solve problems related to the ossification of the network infrastructure or of typical communication APIs, but many of these solutions have had little to no impact on the Internet. One important reason for this is that “de-ossifying” the Internet transport layer to re-enable its evolution is a multi-dimensional problem. This requires the enhancement of multiple components of the end-to-end communication, and effective integration of different techniques. To the best of our knowledge, no concrete, cohesive system has been built to date that provides an overall solution to the “transport-layer logjam”.

A truly evolvable and flexible Internet transport architecture requires a comprehensive transport layer framework that can facilitate integration and cooperation of transport-layer solutions in an application-independent and flexible way. NEAT aims to provide such a transport framework.

Regarding potential impact, NEAT will work towards an open-source reference implementation of the transport system that realises its core functionalities. Also, NEAT’s transport system is targeted for inclusion in future releases of the open-source Firefox Mobile web browser.

Building an in-house transport system can yield the best performance for applications that have special network requirements, and this is the path taken by a few industry giants. However, this path cannot be afforded by most software developers and is fraught with many technical hurdles. By contributing to a free open-source transport system with a large set of functions for efficient communication, NEAT will contribute to a more level playing field for innovative small companies, from which novel Internet applications often come. NEAT will help to make it easier for European software developers to write and deploy applications that efficiently communicate across the Internet, and will enable innovations across the Internet protocol stack.

Related information

Record Number: 190135 / Last updated on: 2016-11-08
Follow us on: RSS Facebook Twitter YouTube Managed by the EU Publications Office Top