IEEE Communications Magazine - June 2017 - page 48

IEEE Communications Magazine • June 2017
46
0163-6804/17/$25.00 © 2017 IEEE
A
bstract
The sockets API has become the standard way
that applications access the transport services
offered by the IP stack. This article presents NEAT,
a user space library that can provide an alternate
transport API. NEAT allows applications to request
the service they need using a new design that is
agnostic to the specific choice of transport proto-
col underneath. This not only allows applications
to take advantage of common protocol machin-
ery, but also eases introduction of new network
mechanisms and transport protocols. The article
describes the components of the NEAT library
and illustrates the important benefits that can be
gained from this new approach. NEAT is a soft-
ware platform for developing advanced network
applications that was designed in accordance with
the standardization efforts on transport services
in the IETF, but its features exceed the envisioned
functionality of a TAPS system.
I
ntroduction
For more than three decades, the Internet’s
transport layer has essentially supported just two
protocols, and the original design of the sockets
application programming interface (API) offered
only two transport services to applications. One
service provided stream-oriented in-order reliable
delivery, manifested in TCP, and the other mes-
sage-based unordered unreliable delivery, mani-
fested in UDP.
Today, more than three decades later, these
are the only two transport protocols common-
ly offered by operating systems to applications.
UDP-based applications are used for a wide vari-
ety of datagram services from service discovery
to interactive multimedia, while TCP became the
dominant protocol for Internet services from web
browsing to file sharing and video content deliv-
ery. While their success has often been attributed
to the robustness of these protocols, during the
past few decades new service requirements have
emerged that are beyond what TCP can deliver or
UDP can offer. Examples include: an interactive
multimedia application may prefer to prioritize
low latency over strictly reliable delivery of data,
but could use partially-reliable delivery to improve
quality while ensuring timeliness; or an application
may be designed to take advantage of multihom-
ing when this is available. UDP has also emerged
as a substrate upon which user space transport
protocols are being developed — many custom-
ized for specific applications (e.g., the QUIC
protocol), where much effort can be expended
re-implementing common transport functions.
A handful of protocols have been proposed to
provide transport services beyond those of TCP
and UDP; most notably, Stream Control Transmis-
sion Protocol (SCTP), Datagram Congestion Con-
trol Protocol (DCCP), and UDP-Lite. However,
none of these have seen widespread use or uni-
versal deployment. The reason behind this is often
attributed to
ossification
of the Internet’s transport
layer, where further evolution has become close
to impossible. This has two major aspects.
Inflexibility of the current socket API:
Applica-
tion programmers need to specify
transport-pro-
tocol-specific
configurations to request a desired
service. This binding to protocols inevitably
requires programmers to recode their applications
to take advantage of any new transport protocol.
It also introduces complexity when there is a need
to customize for different network scenarios, and
choose appropriate transport-protocol-specific
parameters.
Deployment vicious circle:
New protocols
and mechanisms cannot be expected to work
in unmodified networks. Some equipment may
need to be reconfigured, updated, or replaced
to deploy a new protocol. Developers seeking
to use new protocols simply find they cannot be
relied on to work across the Internet. Because the
current socket API requires application develop-
ers to specifically choose a certain protocol, they
tend to avoid using a protocol other than TCP
or UDP, knowing that any others are likely to be
unsuccessful for many network paths. This chick-
en-and-egg situation has made it hard for unused
transport protocols to become deployed in the
Internet — even if they would provide a better
service to some applications.
In this article, we introduce the
NEAT Library
.
This is a software library built above the socket
API to provide networking applications with a
new API offering platform- and protocol-indepen-
dent access to transport services. NEAT is, to the
best of our knowledge, the first prototype imple-
mentation of Internet Engineering Task Force
(IETF) standardization efforts on transport services
NEAT: A Platform- and Protocol-Independent
Internet Transport API
Naeem Khademi, David Ros, Michael Welzl, Zdravko Bozakov, Anna Brunstrom, Gorry Fairhurst, Karl-Johan Grinnemo, David Hayes, Per Hurtig,
Tom Jones, Simone Mangiante, Michael Tüxen, and Felix Weinrank
A
dvances
in
N
etworking
S
oftware
The sockets API has
become the standard way
that applications access
the transport services
offered by the IP stack.
The authors present
NEAT, a user space library
that can provide an alter-
nate transport API. NEAT
allows applications to
request the service they
need using a new design
that is agnostic to the spe-
cific choice of transport
protocol underneath.
Naeem Khademi and Michael Welzl are with the University of Oslo; David Ros and David Hayes are with Simula Research Laboratory;
Zdravko Bozakov and Simone Mangiante are with Dell EMC; Anna Brunstrom, Karl-Johan Grinnemo, and Per Hurtig are with Karlstad University;
Gorry Fairhurst and Tom Jones are with the University of Aberdeen; Michael Tüxen and Felix Weinrank are with Münster University of Applied Sciences.
Digital Object Identifier:
10.1109/MCOM.2017.1601052
1...,38,39,40,41,42,43,44,45,46,47 49,50,51,52,53,54,55,56,57,58,...228
Powered by FlippingBook