| 1. |
- Bozakov, Zdravko, et al.
(författare)
-
Deliverable D2.1 - First Version of Low-Level Core Transport System
- 2016
-
Rapport (refereegranskat)abstract
- 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.
|
|
| 2. |
- Briscoe, Bob, et al.
(författare)
-
Reducing Internet Latency : A Survey of Techniques and Their Merits
- 2016
-
Ingår i: IEEE Communications Surveys and Tutorials. - : IEEE. - 1553-877X. ; 18:3, s. 2149-2196
-
Tidskriftsartikel (refereegranskat)abstract
- Latency is increasingly becoming a performance bottleneck for Internet Protocol (IP) networks, but historically, networks have been designed with aims of maximizing throughput and utilization. This paper offers a broad survey of techniques aimed at tackling latency in the literature up to August 2014, as well as their merits. A goal of this work is to be able to quantify and compare the merits of the different Internet latency reducing techniques, contrasting their gains in delay reduction versus the pain required to implement and deploy them. We found that classifying techniques according to the sources of delay they alleviate provided the best insight into the following issues: 1) The structural arrangement of a network, such as placement of servers and suboptimal routes, can contribute significantly to latency; 2) each interaction between communicating endpoints adds a Round Trip Time (RTT) to latency, particularly significant for short flows; 3) in addition to base propagation delay, several sources of delay accumulate along transmission paths, today intermittently dominated by queuing delays; 4) it takes time to sense and use available capacity, with overuse inflicting latency on other flows sharing the capacity; and 5) within end systems, delay sources include operating system buffering, head-of-line blocking, and hardware interaction. No single source of delay dominates in all cases, and many of these sources are spasmodic and highly variable. Solutions addressing these sources often both reduce the overall latency and make it more predictable.
|
|
| 3. |
- Fairhurst, Gorry, et al.
(författare)
-
Deliverable D1.1 - NEAT Architecture
- 2016
-
Rapport (refereegranskat)abstract
- 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.
|
|
| 4. |
- Grinnemo, Karl-Johan, 1968-, et al.
(författare)
-
Deliverable D3.1 - Initial Report on the Extended Transport System
- 2017
-
Rapport (refereegranskat)abstract
- The NEAT System offers an enhanced API for applications that disentangles them from the actual transport protocol being used. The system also enables applications to communicate their service requirements to the transport system in a generic, transport-protocol independent way. Moreover, the architecture of the NEAT System promotes the evolution of new transport services. Work Package 3 (WP3) enhances and extends the core parts of the NEAT Transport. Efforts have been devoted to developing transport-protocol mechanisms that enable a wider spectrum of NEAT Transport Services, and that assist the NEAT System in facilitating several of the commercial use cases. Work has also started on the development of optimal transport-selection mechanisms; mechanisms that enable for the NEAT System to make optimal transport selections on the basis of application requirements and network measurements. Lastly, another research activity has been initiated on how to use SDN to signal application requirements to routers, switches, and similar network elements. This document provides an initial report on all these WP3 activities—both on completed and on near-termplanned work.
|
|
| 5. |
- Grinnemo, Karl-Johan, 1968-, et al.
(författare)
-
Deliverable D3.2 - Final Report on Transport Protocol Enhancements
- 2017
-
Rapport (refereegranskat)abstract
- This deliverable provides a final report on the work on transport protocol enhancements done inWork Package 3. First, we report on the extensions made to the SCTP protocol that turn it into a viable alternative to TCP and allow to deliver a lower-latency transport service. Next, we describe our work to develop a framework for providing a deadline-aware, less-than-best-effort transport service, targeting background traffic and thus addressing requirements on NEAT from the EMC use case. We also present our efforts to design and implement a latency-aware scheduler for MPTCP, which enables NEAT to offer a transport service that meets the needs of latency-sensitive applications, and that efficiently utilises available network resources. Lastly, this document informs on our work on coupled congestion control for TCP, a mechanism that treats a bundle of parallel TCP flows between the same pair of hosts as a single unit. By efficiently multiplexing concurrent TCP flows, our coupled congestion control alleviates the effects of queueing, and tends to result in a more efficient usage of available bandwidth, where the flows’ aggregate capacity share can be apportioned based on application preferences.
|
|
| 6. |
- Grinnemo, Karl-Johan, 1968-, et al.
(författare)
-
Deliverable D3.3 - Extended Transport System and Transparent Support of Non-NEAT Applications
- 2017
-
Rapport (refereegranskat)abstract
- This deliverable summarises and concludes our work in Work Package 3 (WP3) to extend the transport services provided by the NEAT System developed in Work Package 2, and to enable non-NEAT applications to harness the transport services offered by NEAT. We have demonstrated how a policy- and information-based selection of transport protocol by NEAT could provide a more efficient transport service for web applications. The information on which NEAT makes its transport selection decisions resides in the Characteristics Information Base (CIB). The CIB is populated by various CIB sources, and in WP3 we have designed, implemented, and evaluated various CIB sources, including meta data from mobile broadband networks, passive measurements, IPv6 Provisioning Domain protocols and the Happy Eyeballs mechanism, which caches the outcome of its connection attempts. A key property of NEAT is that it not only “vertically” decouples applications from transport protocols, but also “horizontally”. Particularly, it enables applications to harness information about resource availability and policies from Software Defined Networking (SDN) controllers in managed networks, without these applications actually being SDN-aware. To extend the use of NEAT to non-NEAT applications, we have implemented a BSDcompatible sockets API on top of NEAT and a NEAT proxy that intercepts and replaces standard TCP connections with NEAT flows, i.e., with the transport solutions deemed most appropriate by NEAT.We have also proposed a way for non-NEAT applications to make use of NEAT through the deployment of NEAT-enabled virtual appliances in SDN-controlled networks: connections from these applications are routed via an SDN-controlled proxy that terminates the original connection and replaces it with a NEAT-selected connection.
|
|
| 7. |
- Grinnemo, Karl-Johan, 1968-, et al.
(författare)
-
NEAT - A New, Evolutive API and Transport-Layer Architecture for the Internet
- 2016
-
Ingår i: 12th Swedish National Computer Networking Workshop (SNCNW 2016), Sundsvall, Sweden..
-
Konferensbidrag (övrigt vetenskapligt/konstnärligt)abstract
- There is a growing concern that the Internet trans- port layer has become ossified in the face of emerging novel applications, and that further evolution has become very difficult. This paper identifies requirements for a new transport layer and then proposes a conceptual architecture, the NEAT system, that we believe is both flexible and evolvable. Applications interface the NEAT system through an enhanced user API that decouples them from the operation of the transport protocols and the network features being used. In particular, applications provide the NEAT system with information about their traffic requirements, pre- specified policies, and measured network conditions. On the basis of this information, the NEAT system establishes and configures appropriate connections.
|
|
| 8. |
- Grinnemo, Karl-Johan, 1968-, et al.
(författare)
-
Towards a Flexible Internet Transport Layer Architecture
- 2016
-
Ingår i: The 22nd IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN), Rome, Italy, June 2015. - : IEEE. - 9781467398824
-
Konferensbidrag (refereegranskat)abstract
- There is a growing concern that the Internet trans- port layer has stagnated and become less adaptive to the requirements imposed by new applications, and that further evolution has become very difficult. This is because a fundamental assumption no longer holds: it can no longer be assumed that the transport layer is only in the scope of end-hosts. The success of TCP and UDP and the ubiquity of middleboxes have led to ossification of both the network infrastructure and the API presented to applications. This has led to the development of workarounds, and a range of point solutions that fail to cover many facets of the problem. To address this issue, this paper identifies requirements for a new transport layer and then proposes a conceptual architecture that we argue is both flexible and evolvable. This new architecture requires that applications interface to the transport at a higher abstraction level, where an application can express communication preferences via a new richer API. Protocol machinery can use this information to decide which of the available transport protocols is used. By placing the protocol machinery in the transport layer, the new architecture can allow for new protocols to be deployed and enable evolution of the transport layer.
|
|
| 9. |
- Khademi, Naeem, et al.
(författare)
-
Deliverable D2.2 - Core Transport System, with both Low-level and High-level Components
- 2017
-
Rapport (refereegranskat)abstract
- This document presents the core transport system in NEAT, as used for development of thereference implementation of the NEAT System. The document describes the componentsnecessary to realise the basic Transport Services provided by the NEAT User API, with thedescription of a set of NEAT building blocks and their related design choices. The designof 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 functionalitieshas to be provided by the NEAT Core Transport System. These functionalities take the formof several building blocks, or NEAT Components, each representing an associated implementationactivity. Some of the components are needed to ensure the basic operation ofthe NEAT System—e.g., a NEAT Flow Endpoint, a callback-based NEAT API Framework, theNEAT Logic and the functionality to Connect to a name. Additional components are neededfor: (a) ensuring connectivity, by means of mechanisms for discovery of path support fordifferent protocols; (b) supporting end-to-end security; (c) the ability to apply differentpolicies to influence the decision-making process of the transport system; (d) providingother important functionalities (e.g., a user-space SCTP stack, or gathering statistics forusers or system administrators).This document updates Deliverable D2.1; in particular, the descriptions of NEAT componentspresented here correspond to the implementation status at the time of writing,and as such they replace those in D2.1.
|
|
| 10. |
- Khademi, Naeem, et al.
(författare)
-
Deliverable D2.3 - Final Version of Core Transport System
- 2017
-
Rapport (refereegranskat)abstract
- 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.
|
|
