| 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)
-
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.
|
|
| 5. |
- 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.
|
|
